Date: Thu, 23 Jul 2020 00:18:14 +0300
Hi
sorry to ask you in this way, but I still do not understand what do you
exactly propose?
what exactly is std::containers:: ? new namespace where container size_type
is defined,e.g.
namespace std{
namespace containers{
using size_type = std::size_t;
}
}
?
also how this will work if std::vector is from std::containers::size_type?
std::vector<int> v1(std::containers::size_type{42}, 42);
e.g. how this can compile - it will be ambiguous:
std::vector<std::containers::size_type> v1(std::containers::size_type{42},
42);
I believe this is recognized not by the type, but by the
std::initializer_list.
regards
N
On Thu, Jul 23, 2020 at 12:07 AM Lyberta via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Scott Michaud via Std-Proposals:
> > Do the library maintainers have any established opinion about strongly
> typing parameters that can be ambiguous?
>
> I was thinking about making size_type and difference_type strong types.
> Perhaps with a shallow semantics. As in
>
> std::vector<Foo>::size_type is
> std::allocator_traits<std::allocator<Foo>>::size_type but it is simply a
> class with raw integer
> template parameter. For example std::containers::size_type<unsigned long
> long>.
>
> Deep semantics would actually encode the whole container as template
> parameter like so:
>
> std::containers::size_type<std::vector<Foo>>
>
> This will make the following code ill-formed:
>
> std::vector<Foo> a;
> std::vector<Bar> b;
> auto c = a.size() + b.size();
>
> Because the containers are unrelated so their sizes are unrelated too. Of
> course, going this route is maybe too much.
>
> >
> > I'll illustrate what I mean with a concrete use case: std::vector.
> >
> > In C++, there is a constructor that takes a single size_type and creates
> a vector with n default-constructed elements.
>
> This is definitely one of the worst blunders in standard library.
>
> std::vector<int> v1(42, 42);
> std::vector<int> v2{42, 42};
>
> Produce completely different things. Have we had something like
>
> std::vector<int> v1(std::containers::size_type{42}, 42);
>
> Results would be slightly better, but it would produce problems with
> std::vector<std::containers::size_type<...>>. Initializer
> list ctors really need different syntax.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
sorry to ask you in this way, but I still do not understand what do you
exactly propose?
what exactly is std::containers:: ? new namespace where container size_type
is defined,e.g.
namespace std{
namespace containers{
using size_type = std::size_t;
}
}
?
also how this will work if std::vector is from std::containers::size_type?
std::vector<int> v1(std::containers::size_type{42}, 42);
e.g. how this can compile - it will be ambiguous:
std::vector<std::containers::size_type> v1(std::containers::size_type{42},
42);
I believe this is recognized not by the type, but by the
std::initializer_list.
regards
N
On Thu, Jul 23, 2020 at 12:07 AM Lyberta via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Scott Michaud via Std-Proposals:
> > Do the library maintainers have any established opinion about strongly
> typing parameters that can be ambiguous?
>
> I was thinking about making size_type and difference_type strong types.
> Perhaps with a shallow semantics. As in
>
> std::vector<Foo>::size_type is
> std::allocator_traits<std::allocator<Foo>>::size_type but it is simply a
> class with raw integer
> template parameter. For example std::containers::size_type<unsigned long
> long>.
>
> Deep semantics would actually encode the whole container as template
> parameter like so:
>
> std::containers::size_type<std::vector<Foo>>
>
> This will make the following code ill-formed:
>
> std::vector<Foo> a;
> std::vector<Bar> b;
> auto c = a.size() + b.size();
>
> Because the containers are unrelated so their sizes are unrelated too. Of
> course, going this route is maybe too much.
>
> >
> > I'll illustrate what I mean with a concrete use case: std::vector.
> >
> > In C++, there is a constructor that takes a single size_type and creates
> a vector with n default-constructed elements.
>
> This is definitely one of the worst blunders in standard library.
>
> std::vector<int> v1(42, 42);
> std::vector<int> v2{42, 42};
>
> Produce completely different things. Have we had something like
>
> std::vector<int> v1(std::containers::size_type{42}, 42);
>
> Results would be slightly better, but it would produce problems with
> std::vector<std::containers::size_type<...>>. Initializer
> list ctors really need different syntax.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2020-07-22 16:22:10