220 32550 <74822f32-cca8-44c4-bcc2-cc35f22e8d08@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: relaxing rules for ternary operator. Allow incompatible types. Date: Sun, 21 May 2017 07:11:33 -0700 (PDT) Lines: 130 Approved: news@gmane.org Message-ID: <74822f32-cca8-44c4-bcc2-cc35f22e8d08@isocpp.org> References: <1b5ee8eb-53df-4e98-af2f-829c7bc2e5b2@isocpp.org> <9064929.QEV8q21eIZ@tjmaciei-mobl1> <99350a9e-0c6b-468d-9761-f2b2b052275e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2215_1340075161.1495375893454" X-Trace: blaine.gmane.org 1495375895 24526 195.159.176.226 (21 May 2017 14:11:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 May 2017 14:11:35 +0000 (UTC) Cc: ma.kalbfuss@web.de To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBFWAQ3EQKGQETANODXY@isocpp.org Sun May 21 16:11:30 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dCRZx-0006Ez-Mi for gclcip-std-proposals@m.gmane.org; Sun, 21 May 2017 16:11:29 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id m28sf26956689uab.9 for ; Sun, 21 May 2017 07:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references: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=Edl9kJsbTH8RB0JyynLs+TDSqegg+gVUtNStYnh3NdA=; b=AIzHr/C63ZvlvC0uaB78zWwA7DxH7Ec4wxvuEOOeetRGN3DCxhXmoMpOPDP8ilm+3b 4O9OdlkZMFG61n7R2jBDKTVpUhq/4xmuiqdxMq24cn7wKD5ckXlMP0kN5ugFEfib6iHT rnK/9QY0vwKhAXPPJ592LeJfRo8Cn2cDHKAkaeKZn/gYf9jFsSoGhxBAS1q+pJ7QXWSN sxVywFdGDpSFyIMMfgs0aIKnrpzr7vz17jHVxQfVftuzbYMsmyeE2X9oXwy/3KwbM346 fRnLxVsw8sz2VAKVcapIZJFhF777xysSVVTrydcq2hLXgGlZNqX79ncZsdCApxFnq1uS C9Kw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references: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=Edl9kJsbTH8RB0JyynLs+TDSqegg+gVUtNStYnh3NdA=; b=KAcKmykG64ilmwqJlBFSTym9+ZkZIk8NQyIxoE5wTb9Rdz22352Gk/f/m/TGD14DXX aEbLZSWPlW+D4DDnKtE+ELIKXsrQj1TQf+oHb8tBhUUKDnyz9DV1vVnf7MgI86Isw0db R9fYkVvKCqdU0BJOOhmTgp1sBDvALAvsbnfgf64dAY4zge1r2utkxfPVRLH9QAinR0Wl 0apPxp7AO2goTDoM9qxNScj3SLLasREheR+4S9T59WHOtRuQ8MaTTJJ6xq2ma2rem79b WHcBivISSjAHGXyBKzHD8kHaswo9mpsoF9xowDYcBEOMXEvW0A9c4FYFIWmLVzZuPGj2 HblQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references: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=Edl9kJsbTH8RB0JyynLs+TDSqegg+gVUtNStYnh3NdA=; b=rxLYyJlOLDZP2hIyS6whZrwvvaAiG08vCvQOJl4XLRmgYcybQtubqu8hhUq3ruuuKJ 3SbRxe1dn8jtw0W0bvOhiVEmCW30elQeVhcVoRsucvZZb7es38HwPMexTQCu9aHf+jNP yy/0uhtAApmifdqFpsNbNFqVuh44ZZWvo03/B+1GMaxgIjniPQzI98nGR+BU9/tAy0ML duzwkejTemG458sHxO2RzHpqSCy7/0xWonPBwErQOEqnGCDEkCc7DBiKjUswUQryWqP2 t4r42c26QA1Xmqomf5yGPdoZAESCcJeBZLaG6SxQvAwSnk3iaGoUph6CfaOyN8JpklwJ +BvA== X-Gm-Message-State: AODbwcCY3O+LRE1esw/dWtBMr8ivcgqEy0mLGfTqgpsRH2OUrBBIgHZs AQpIrNH8XMuO+dy3 X-Received: by 10.31.6.144 with SMTP id 138mr5084065vkg.5.1495375894788; Sun, 21 May 2017 07:11:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.35.25 with SMTP id j25ls1909367otb.33.gmail; Sun, 21 May 2017 07:11:33 -0700 (PDT) X-Received: by 10.157.37.213 with SMTP id q79mr392087ota.11.1495375893961; Sun, 21 May 2017 07:11:33 -0700 (PDT) In-Reply-To: <99350a9e-0c6b-468d-9761-f2b2b052275e@isocpp.org> X-Original-Sender: jmckesson@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:32550 Archived-At: ------=_Part_2215_1340075161.1495375893454 Content-Type: multipart/alternative; boundary="----=_Part_2216_420638624.1495375893454" ------=_Part_2216_420638624.1495375893454 Content-Type: text/plain; charset="UTF-8" On Sunday, May 21, 2017 at 5:03:45 AM UTC-4, ma.ka...@web.de wrote: > > I revisited your statement, that this isn't possible, because the type > would be determined at runtime. I have to disagree, now. It is possible at > compile time. > I question whether the value of such a construct is worth the code readability issues. You're effectively creating template code within existing code, arbitrarily. You're making it difficult for a user to track down the type of an object. Since `auto` and `decltype` have become standard C++, there has been a move away from easily being able to determine the type of an object. And in many cases, it's fine that we don't see the type spelled out, because it's obvious by inspection what it is. But once you start saying that an object's type could be expression A or expression B or expression C, etc, it becomes difficult to follow the logic of our code. Considering the potential downside in making code easily follow-able, I would like to see some evidence that people frequently use idioms like: auto f = [&](auto x) { x.doit(); }; runtime_condition ? f(A{}) : f(B{}); Because if they don't, then the feature's motivation is weak. Alternatively, I would say that it needs to be a *different* ternary expression. Even if it's something as simple as `??` rather than `?`, it would at least clue us in as to exactly *when* a user is going to do something like that. It should also be noted that this is coming very close to having full-on language support for variant types. Which really means pattern matching and such. Perhaps there's a better feature deeper down here that could handle this in a different way. -- 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/74822f32-cca8-44c4-bcc2-cc35f22e8d08%40isocpp.org. ------=_Part_2216_420638624.1495375893454 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, May 21, 2017 at 5:03:45 AM UTC-4, ma.ka...@web.= de wrote:
I re= visited your statement, that this isn't possible, because the type woul= d be determined at runtime. I have to disagree, now.=C2=A0 It is possible a= t compile time.

I question whether the value= of such a construct is worth the code readability issues. You're effec= tively creating template code within existing code, arbitrarily. You're= making it difficult for a user to track down the type of an object.
Since `auto` and `decltype` have become standard C++, there has been a mov= e away from easily being able to determine the type of an object. And in ma= ny cases, it's fine that we don't see the type spelled out, because= it's obvious by inspection what it is. But once you start saying that = an object's type could be expression A or expression B or expression C,= etc, it becomes difficult to follow the logic of our code.

Consider= ing the potential downside in making code easily follow-able, I would like = to see some evidence that people frequently use idioms like:

auto f =3D [&](auto x) {<= /span> x.doit(); };
runtime_condition ? f(A{}) : f(B{});

Because if they don't, th= en the feature's motivation is weak.

Alternatively, I would say = that it needs to be a different ternary expression. Even if it's= something as simple as `??` rather than `?`, it would at least clue us in = as to exactly when a user is going to do something like that.
It should also be noted that this is coming very close to having full-on l= anguage support for variant types. Which really means pattern matching and = such. Perhaps there's a better feature deeper down here that could hand= le this in a different way.

--
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/74822f32-cca8-44c4-bcc2-cc35f22e8d08= %40isocpp.org.
------=_Part_2216_420638624.1495375893454-- ------=_Part_2215_1340075161.1495375893454-- .