Date: Thu, 29 Oct 2020 22:03:40 +0100
Hello,
Il 29/10/20 16:33, Arthur O'Dwyer ha scritto:
> In your particular case of {x,y}, I'm also ambivalent. Influential
> people like Nevin Liber (P1163
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1163r0.pdf>)
> have expressed strong aversion to HORSE, so, to a first approximation,
> HORSE will never happen. Also, people today are physically prevented
> from doing CART. Your proposal proposes to permit people to do CART,
> knowing that HORSE will never happen.
> So there are (at least) two possible positions: Nicol's "I don't want
> CART without HORSE" and my "well, we obviously can't get HORSE
> /before/ CART, so we might as well get CART and see if that helps the
> HORSE to follow."
I am not personally making any prediction whatsoever on whether we will
ever get HORSE or not; I do not have any secret agenda! :) If this kind
of proposals are useful to spur old discussions, by all means, let's
have them. (But in another thread :-P. By the way, P1163 got rejected).
My *strong* position is: there are plenty of legitimate, non-niche use
cases for initializer lists that don't have the HORSE problems. These
initializer lists are already usable with certain stdlib functions, but
they're not usable with other functions (sometimes strongly related,
e.g. push_back/erase) because of an oversight. My aim is to simply close
that oversight. I definitely do not believe that improving this CART is
going to increase the adoption of "wrong" usages so much that this will
effectively block any future tentative of fixing the HORSE.
Thanks for your feedback, stay safe,
Il 29/10/20 16:33, Arthur O'Dwyer ha scritto:
> In your particular case of {x,y}, I'm also ambivalent. Influential
> people like Nevin Liber (P1163
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1163r0.pdf>)
> have expressed strong aversion to HORSE, so, to a first approximation,
> HORSE will never happen. Also, people today are physically prevented
> from doing CART. Your proposal proposes to permit people to do CART,
> knowing that HORSE will never happen.
> So there are (at least) two possible positions: Nicol's "I don't want
> CART without HORSE" and my "well, we obviously can't get HORSE
> /before/ CART, so we might as well get CART and see if that helps the
> HORSE to follow."
I am not personally making any prediction whatsoever on whether we will
ever get HORSE or not; I do not have any secret agenda! :) If this kind
of proposals are useful to spur old discussions, by all means, let's
have them. (But in another thread :-P. By the way, P1163 got rejected).
My *strong* position is: there are plenty of legitimate, non-niche use
cases for initializer lists that don't have the HORSE problems. These
initializer lists are already usable with certain stdlib functions, but
they're not usable with other functions (sometimes strongly related,
e.g. push_back/erase) because of an oversight. My aim is to simply close
that oversight. I definitely do not believe that improving this CART is
going to increase the adoption of "wrong" usages so much that this will
effectively block any future tentative of fixing the HORSE.
Thanks for your feedback, stay safe,
-- Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
Received on 2020-10-29 16:03:48