Post by Arthur O'Dwyer
That's a fair analogy; but I still can't picture what kind of core
language feature would help here. With lambdas it was pretty
obvious what the core feature was; the only bikeshedding was over
the spelling of . With customization points, it's not real clear
/what/ we're trying to spell in the first place. A new call
syntax? A new way of doing name lookup? A new way of defining
Reaching back into the archives, the original range-based for loop
which would invoke std::Range<_RangeT>::begin(__range) and
Thanks for adding this old link. The calling interface should be even
more simple std2::range::begin(aRange) and std2::range::end(aRange) but
not simpler: std2::begin(aRange) and std2::end(aRange).
IMO, the std2 customization mechanism as proposed for the Range TS
doesn't scale for the C++ standard library and the approach cannot be
used by the users to define his own customization points. The last could
be seen as not a problem for the standard C++, but people must solve
concrete problems and they copy the C++ library design as it should be
the correct one, but they cannot in this case. See for example the
customization mechanism of Boost.Hana and many other generic libraries.
If they use ADL as customization point, they can not support C++
standard library types.
We will see more a more concepts very soon. In the same way we associate
a member function to a class, we should associate a customization point
to a concept and name it. There shouldn't be a confusion of which
customization point belongs to what concept. It is not the same
product_type::get than sum_type::get, container::size than memory::size.
begin/end is not something limited to ranges. When I say name it I mean
that the user must name the concept and the function name when she want
to call it and that the customization is done explicitly using this
concept name as well. This is not the design used in on the C++ standard
up to C++17 and will not change for C++20 with the current direction.
We would need more a more customization points if we continue to do
generic programming and not only on the C++ standard library. Having all
these customization points in a flat namespace don't scale, the
customization points become pseudo keywords. We need to scope them. We
have namespaces to manage with scope, and the standard library is not
using them (the exceptions of chrono and filesystem are domain
namespaces which of course is a very good use of namespaces). I expected
to have a std2::ranges namespace in the future STD2 to signal that
anything there was talking about customization points of the the Range
concept and the algorithms that work with this concept. Instead, IIUC we
will have again a flat std2 namespace without structure. I know that
this will make the names longer, but we have other C++ features that
help us, as namespace aliases. Language that don't have namespaces rely
on prefixes to ensure a unique meaning for a customization point. C++
is more powerful and we should use this power for the standard library.
I don't see the advantage of having implicit mappings that are based on
syntactical vraisemblance. Why a class defining begin() and end()
function members should become a Range if the functions don't support
the Range semantics. While sometimes it is possible to ensure almost all
the semantic concerns others it isn't so easy. At the end a syntactical
mapping has more liabilities than advantages as most of the short term
I know that we want backward compatibility and any alternative
customization approach needs to address it. This doesn't mean that we
should base our future customization strategy on an approach ADL that
has a lot of problems, see [N1691].
I agree that we need a language feature to define customization points
and a way to customize them. Other languages have already do that with
success. C++ is a complex language and we don't want to add anything
that make it even more complex. I believe however that we really need to
solve this problem at the languages level. IMHO, C++0x addressed in part
this problematic but the C++ standard abandoned this direction and
people as Bjarne Stroustrup and many others don't want to consider any
proposal that has an explicit concept/customization points mapping. This
means that people are trying to solve the problem at the library level.
I believe that the proposed std2 customization mechanism has his merits
on the continuation of this direction. The approach solves already some
important problems, but the solution doesn't takes in account the
problems addressed in [N1691] and is more complex that the lambda user
is able to design. As Bjarne Stroustrup says, "Make simple thing simpler".
Sorry, but I don't have a language proposal. In the mean time I use an
alternative customization point mechanism (close to the one of
Boost.Hana) that is explicit in the calling side and explicit in the
customization side, but the customization solution is a little bit
cumbersome. I use it on some of my proposal as Nullable, Factories,
Product Type. I'm using the same approach also for other on going
proposal I'm working on, as e.g. for Sum Types, Ordinal types, Functors
or Monads. These proposals don't propose function object to represent
the user interface but this could be considered. IMHO, providing
function objects is orthogonal to the customization point approach and
the fact that the current STD2 approach requires the use of function
objects shouldn't be considered as a goal. As others have noted we have
some proposals on overloads sets that would make it very easy to provide
a function object associated to an overload set.
The current customization points could be adapted to this explicit
approach while preserving backward compatibility, as e.g. for Swappable,
Hashable and Range. I don't see these proposals as a final solution and
I hope these proposals could inspire some language solution(s) (some
kind of explicit namespace, partial template class specialization from
unrelated namespaces, traits, ...) or at least a better library solution.
[N1691] Explicit Namespaces
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
To post to this group, send email to email@example.com.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3f13697d-a5d6-d802-68b6-291c79f0b041%40wanadoo.fr.