220 28273 <0892f743-bca2-4f18-b023-d4a57cea60fb@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Something is better then nothing: Please, relax Initializer List use with operators! Date: Sun, 18 Sep 2016 05:41:39 -0700 (PDT) Lines: 296 Approved: news@gmane.org Message-ID: <0892f743-bca2-4f18-b023-d4a57cea60fb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2833_368196602.1474202499435" X-Trace: blaine.gmane.org 1474202515 1798 195.159.176.226 (18 Sep 2016 12:41:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 18 Sep 2016 12:41:55 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBBEX7K7AKGQELBTY6MY@isocpp.org Sun Sep 18 14:41:50 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1blbPh-0007Jm-9O for gclcip-std-proposals@m.gmane.org; Sun, 18 Sep 2016 14:41:41 +0200 Original-Received: by mail-oi0-f72.google.com with SMTP id t83sf21615252oie.0 for ; Sun, 18 Sep 2016 05:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=6BdvWgAYhGnvYbx0C682npBJKbHas5t4Ln+xhwjsN38=; b=kzmlk2VEEGKkyZv6xMCX+5RNNxv77252GgeHf0kEFvgKuRF/duunAy76SnB3VQ+pBh eT+EYyMVuVsPQ/ROlQOZH9CHOm1+aDykjavtxK7oBggIHCM/4XbzVP0qWEaVsGRW5MRP tvgsZM1PFm0RT/tSaxkxF3cIi5YHb9mpjS92v1XbtfNyJjhxBO6zP16x5B8V10Y64zyN tJI8k8tBnLeZTTwW1lylvn9QbI4kfOcc001CXiyyD+yjYmvEJ0YQNy93W9s7FqVzL1ol R5S6dvpKLg4gRW5gLN/AcE7rI4R20b2mezy5dGk9E5lJIfd1WNOaiJQ+V9IpimgRBJeJ xq9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=6BdvWgAYhGnvYbx0C682npBJKbHas5t4Ln+xhwjsN38=; b=PW8mnN1/eanNXOuI+tgFJdqdo99tjCdxYnzA0q2ZSigIBJZ5AitNsFnprqEec605Fv ZqWsFQwpoRRv+upYTZsI76FyBcj+7VVerzmnUN2U629EisbsCpWCi9jcX6hJhqLOI6Nv WUTqh3iYsrxxfm6N36pPJL9z6Oh368Yp3pMy4CrW+a1iwn4tp6jUxis9S65G4YBxZqZT L7gMef70qT21SSrmzEMdTrke29WgqNbE9FIFUCfO38CqrDFvYzJT6oKsOt4+CubXaY0T PzSjF9TK8pCfEbRFQkcwHHzhndNYVcEFO3Hut9Vy61dQx5HwVoknlmSHqIDWZyAUJWJH p0IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=6BdvWgAYhGnvYbx0C682npBJKbHas5t4Ln+xhwjsN38=; b=bL07yCTrBZTIIeF/Vs86GJXZhRhBQODX6w8n9UpUYd4GflE31u9bj/Kq7Wp2kkzPrO rU6WfCS09CgWAMKfF+nf2Y8Zx2iBIvQbfBJ/fK+rOYBMpPHjXIuDqXz7OiN8eWGAQ7fj 0s5zJLwXYKie6Z8GoCWI6cGjfkjNONAuXJ6CJVHx5FQ9k9I58x5FeQ1F54rzJ9z1u9Nw xo8gR4usHLkvdNrug5QQsz7MK9F14zMSm2emNo7qMtQ9ZkqaqI0Fv6fMhX0gsHRw3+cm 9fz+BgPJNzNwzc244qcPc65NyG3kXWqAjA3G8z5Vpz13ksEU0LLwaOk2cj5S/Ix9UrP1 zIoQ== X-Gm-Message-State: AE9vXwN5zRd7+25dg8wGTLNhZW1b+RLf7kn3Xccnuk6Bv7+fXRIDUPK93+gXMX9ItWzwjw== X-Received: by 10.157.10.21 with SMTP id 21mr2778792otg.62.1474202502475; Sun, 18 Sep 2016 05:41:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.151.209 with SMTP id z200ls2706825iod.22.gmail; Sun, 18 Sep 2016 05:41:40 -0700 (PDT) X-Received: by 10.36.137.67 with SMTP id s64mr179410itd.1.1474202500299; Sun, 18 Sep 2016 05:41:40 -0700 (PDT) X-Original-Sender: MihailNajdenov@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:28273 Archived-At: ------=_Part_2833_368196602.1474202499435 Content-Type: multipart/alternative; boundary="----=_Part_2834_286874145.1474202499435" ------=_Part_2834_286874145.1474202499435 Content-Type: text/plain; charset=UTF-8 Hello, in a recent search about why is Initializer List limited so much (cant be used in arithmetics, assignment, etc), I came to this post : http://stackoverflow.com/a/11445905/362515 Basically the problem is, Initializer List is impossible to work in any situation where operators are used - parsing such an expression will be to complex. That is fine. However support in limited, but well defined scenarios is possible and I believe the benefits will still outweigh the confusion why it is not working in some contexts. What is more *there is already a confusion why it is not working in "similar contexts"!* For example *from the user perspective assignment and comparison are "similar" contexts of use - one is "are you that thing" the other is "become that thing". * Needless to say the syntax is, as we know, dangerously close "==" vs "="*.* If for instance is allowed *only the type of the RHS in operator to be deduced from an init-list* and expression is dissuaded to start with a init-list, not only many if not all use cases will be possible, *but it will be somewhat easier to teach why the other case is to available.* Back to the example - it is hard to explain why this is working: Point p; p = {-1, -1}; but this is not: if(p == {-1, -1}) return; *But this is actually relatively easy to explain why it's not working*: if({-1, -1} == p) return; Basically the user will learn at some point that {,} by itself is nothing more the a bunch a character, shortcut to create something in given context - it is not an expression, not a value, not even an initializer_list He will see there is a difference b/w if(-1 == p.x) and if({-1, -1} == p) He will see that in the first case he is creating something concretely - he is saying 'create the object int from that -1 I gave you", but in the last case he is just saying "I am giving you two ints in a packet". *The user clearly sees, he is not saying what to create with these two ints - might be a pair, a size, an array. The user knows he is underspecifying at that point. * *He just hopes the context is enough for the compiler to do the work.* At this point we just step in and say - no, you must give the context before you ask us to do the guessing! We'll guess p == {1-, -1}, we'll guess p + {.5, 0}, we might even guess p = {10, 10} - p. *But we'll not guess an expression which starts with enigma and a context to solve it given later.* Thing is, *the user will not be surprised by that rule. he knows it already - this is the reason we have a trailing return type! * *For the user will not be something new if he is required to do something from left to right if he'll benefit (quite a lot) from it. * *"I will help you, if you help me" said the parser.* As said, in its current state init-list usage is both extremely limited *and* it is hard to explain why. If the rules are relaxed it will be both much, much, much more useful *and* easier to explain why some usage is not allowed. The point I am trying to make is - I don't consider "allowing initializer lists as right-hand, but nor as left-hand arguments to most operators is too much of a kludge". Init-list, {,} is magic, it does not have to work in *all cases*, it is there to help you* as much as it can. *And now it works in roughly half of the cases although it can do much more. Please let it do more. (And actually making it more predictable in the process). *P.S* I must stress it is not just about "less typing", it is about less type commitment - Point might be QPoint next year or MyPoint the other, but it will always, even in a million years will be represented by two numbers. *Bonus:* This must work, it really must work: const auto e = car ? car->engine() : {}; We know it does not but it should, no reason why not - first arg is given, second arg is given, the the third must the same type as the second, so we have everything to deduce it! -- 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 std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0892f743-bca2-4f18-b023-d4a57cea60fb%40isocpp.org. ------=_Part_2834_286874145.1474202499435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, in a recent search about why is Initializer List li= mited so much (cant be used in arithmetics, assignment, etc), I came to thi= s post :=C2=A0http://stackoverflow.com/a/11445905/362515

Basically the problem is, Initializer List is impossible to work in any si= tuation where operators are used - parsing such an expression will be to co= mplex.

That is fine.

Howe= ver support in limited, but well defined scenarios is possible and I believ= e the benefits will still outweigh the confusion why it is not working in s= ome contexts.=C2=A0
What is more there is already a=C2=A0confu= sion why it is not working in "similar contexts"!=C2=A0
=

For example from the user perspective assignm= ent and comparison are "similar" contexts of use - one is "a= re you that thing" the other is "become that thing".=C2=A0
Needless to say the syntax is, as we know, dangerously close &= quot;=3D=3D" vs "=3D".

If for instance is allowed only the type of =C2=A0the RHS in operator = to be deduced from an init-list=C2=A0and expression is dissuaded to sta= rt with a init-list, not only many if not all use cases will be possible, <= b>but it will be somewhat easier to teach why the other case is to availabl= e.

Back to the example - it is hard to explain= why this is working:
Point p;p =3D {-1, -1};

but this is not:

if(p = =3D=3D {-1, -1}= ) <= span style=3D"color: #008;" class=3D"styled-by-prettify">return;
<= /code>


But this is actually relativel= y easy to explain why it's not working:
if({-1, -1} =3D=3D<= /span> p) return;

Bas= ically the user will learn at some point that {,} by itself is nothing more= the a bunch a character, shortcut to create something in given context - i= t is not an expression, not a value, not even an initializer_list<T><= /div>

He will see there is a difference b/w=C2=A0
if(-1 =3D=3D p.x) =
=C2=A0and
=
if({-1, -= 1} =3D=3D p)

He will see t= hat in the first case he is creating something concretely - he is saying &#= 39;create the object int from that -1 I gave you", but in the last cas= e he is just saying "I am giving you two ints in a packet".=C2=A0=

The user clearly sees, he is not saying what t= o create with these two ints - might be a pair, a size, an array. The us= er knows he is underspecifying=C2=A0at that point.=C2=A0
=
He just hopes the context is enough for the= compiler to do the work.

At this point= we just step in and say - no, you must give the context before you ask us = to do the guessing!
We'll guess p =3D=3D {1-, -1}, we'll = guess p + {.5, 0}, we might even guess p =3D {10, 10} - p.
But= we'll not guess an expression which starts with enigma and a context t= o solve it given later.

Thing is, the user will no= t be=C2=A0surprised by that rule. he knows it already -=C2=A0=C2=A0this is = the reason we have a trailing return type!=C2=A0
For the u= ser will not be something new if he is=C2=A0required to do=C2=A0something= =C2=A0from left to right if he'll benefit (quite a lot) from it.=C2=A0= =C2=A0
"I will help you, if you help me" said th= e parser.

As said, in its current state= init-list usage is both extremely limited=C2=A0and=C2=A0it is hard = to explain why.
If the rules are relaxed it will be both much, mu= ch, much more useful and=C2=A0easier to explain why some usage is no= t allowed.

The point I am trying to make is - I do= n't consider "allowing initializer lists as right-hand, but nor as= left-hand arguments to most operators is too much of a kludge".
Init-list, {,} is magic, it does not = have to work in all cases, it is there to help you as much as it = can. And now it works in roughly half of the cases although it can do m= uch more.=C2=A0
Please let it do more. (And actually making it mo= re predictable in the process).

P.S
I must stress it is not just about "less typing", it is about = less type commitment - Point might be QPoint next year or MyPoint the other= , but it will always, even in a million years will be represented by two nu= mbers.

Bonus:
This must work, it = really must work:
const auto e =3D car = ? car->engine() : {};
=C2=A0We know it does not but i= t should, no reason why not - first arg is given, second arg is given, the = the third must the same type as the second, so we have everything to deduce= it!

=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/0892f743-bca2-4f18-b023-d4a57cea60fb= %40isocpp.org.
------=_Part_2834_286874145.1474202499435-- ------=_Part_2833_368196602.1474202499435-- .