220 40616 <55c9a427-37c7-4a22-8e8a-8c5f00059852@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: hubert.reinterpretcast@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: auto and expression templates using attributes Date: Thu, 18 Oct 2018 20:12:43 -0700 (PDT) Lines: 154 Approved: news@gmane.org Message-ID: <55c9a427-37c7-4a22-8e8a-8c5f00059852@isocpp.org> References: <2f62daa1-aeb8-4a56-af97-d622a8b9030a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3328_1190624742.1539918763381" X-Trace: blaine.gmane.org 1539918640 22563 195.159.176.226 (19 Oct 2018 03:10:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2018 03:10:40 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD373PPKVMHBBLEXUXPAKGQEEEJ2RGQ@isocpp.org Fri Oct 19 05:10:36 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f198.google.com ([209.85.219.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDLBL-0005l2-Cj for gclcip-std-proposals@m.gmane.org; Fri, 19 Oct 2018 05:10:35 +0200 Original-Received: by mail-yb1-f198.google.com with SMTP id u42-v6sf18819540ybi.3 for ; Thu, 18 Oct 2018 20:12:46 -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:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=SeOFvPMxQz29RdH4p9eEBf2dqEMUKWhaPt4it8wZS1M=; b=IG++BfgSkpHvDnwOuoljvUbzNuWVrUCwPz35J7shM+PZ8c+mjCaya8rUX4Rrac7oOE chHshRMEnX8ipLUo8AqZE9+2kP6PLYjGC4bE6H7yPZCnr5OHimJqGPtvfdiuQSm6tVuZ RqBcGh593+Iqy2QQ5Vfu5RWz33irIwyivSnCoYDHVHv+sZ/z5D4Eh/AlRQ4SO41r88/m 7mPDmpUReFUyXWKeEXGbTKX5qyb/0tfCn//wZGaAgnB7SIHD7aoXlmoF3M+ze6NXQpAW KQDOirMHqSi4pgvlvEFu2WjGBJegSOr+pJuv9a0Nth1gjIfysJbWCmH8eaO02QAk2F0v Eaxw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=SeOFvPMxQz29RdH4p9eEBf2dqEMUKWhaPt4it8wZS1M=; b=IVUk/N1advfcPsLDxSOS5FTjx7/Ux+O5GRHKopUkxQ7seBDiqQFUb1kvKvYItOBgiX 9uazWNwUsiz7yVW81cdx3p+2zTGGbPASZuusr0y5dIlkmUV1kuZtHJOznFz9EHlfKJOV cAwTvMg4TyMz9opJ877VZOrVYTePDhVb5vHp3Em5gtSH0F3WaKpUXIhRJfRzuDtCUX2G jPDaSw+CQkadm06fbXWVHNt5n1crnkKFdkdNOQKcykwYseCvmN3R5EujOsFdZFD/17vN QpsIAxMG13jtDLwpt1BYPEtItRUUtz+oFGrQiwgwUAhLl4+sRb+AIgoUmOk/1ihbbFPt 5p2A== 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: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=SeOFvPMxQz29RdH4p9eEBf2dqEMUKWhaPt4it8wZS1M=; b=j36qHVWL5chkmIqm1/2Tyk8z7AWzssm5KLsNmvy92c+2BpfN3JFvHmYII9HQPWOTeV fEIsGxD+Zl5E6ZT+E/YhyvEEPsseQn58um1GuWtVgmeKZD8284I0PfoqTN26peATE6yG o8jCjAk904/NcfgkPJHOiA94P893hzMI+OYm1vJ9iijLDR9JwfNyoBRVMHXFriYbXn2M 8RpzZVsDWs7hDHChlh10AhTRifKJY/ToMTmBdgQkeFYOyrAgEdZwvk4qGePQHjug+whM uihUf3OFYZsaG5A7OO9SoKg70PCRJrXIyoNCvXwo0sRF+RoexN2NVviw2M7v0LM3kYxc TcRA== X-Gm-Message-State: ABuFfojrTAQUBTAjFYtIZYCjgLTmWUlNaropcmPl+peHxuIA9XwMMSXu VP7G1g0aTPtBu++ZGDo/nSP64A== X-Google-Smtp-Source: ACcGV61CYYI9oRq9YFssnGx9IbZA4FHR87VchJbZTvv4DZiK4NN7r4FHmBzWbUlUrho5XsG61I+p0Q== X-Received: by 2002:a25:ef05:: with SMTP id g5-v6mr17749965ybd.78.1539918765619; Thu, 18 Oct 2018 20:12:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:15c6:: with SMTP id 189-v6ls9547778ybv.20.gmail; Thu, 18 Oct 2018 20:12:44 -0700 (PDT) X-Received: by 2002:a25:d90a:: with SMTP id q10-v6mr409711ybg.0.1539918764155; Thu, 18 Oct 2018 20:12:44 -0700 (PDT) In-Reply-To: <2f62daa1-aeb8-4a56-af97-d622a8b9030a@isocpp.org> X-Original-Sender: hubert.reinterpretcast@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:40616 Archived-At: ------=_Part_3328_1190624742.1539918763381 Content-Type: multipart/alternative; boundary="----=_Part_3329_2126778946.1539918763381" ------=_Part_3329_2126778946.1539918763381 Content-Type: text/plain; charset="UTF-8" On Tuesday, October 16, 2018 at 4:44:22 AM UTC-4, Till Heinzel wrote: > > I have previously worked a lot with expression templates, and using them > together with auto is a pain - errors crop up all the time, and I ended up > wrapping most of the functionality away. > I have been looking at P0672R0 > and > I think that sounds like a pretty good idea, but it also seems to be a > quite invasive solution. I also looked at this discussion: a C++17 > library solution to N4035, expression templates, auto and class template > argument deduction > , > which does not seem to address the problem, as it is still up to the user > to see when to use the proposed type. > > So instead, I would propose adding a new attribute [[temporary_type]] that > tells the compiler to emit a warning when an object of the type is used in > a non-temporary context. I am not too certain on value categories, but I > think it would work well if this would just mean a warning when the object > is an lvalue. The user then knows to call some function, or to use a cast > or an explicit type for the assignment, whatever works in the context of > the library. > An accompanying attribute could be [[allowed_temporary_lvalue]], to > suppress the warning at the call site. This would allow using the type > warning-free within the library where it is created, and clearly express > that this is a special case, not the primary use case for this type. > > While I find P0672R0 interesting, I also think it may be overkill for a > relatively niche problem. I ran into it using armadillo (linear algebra), > the Wikipedia site specifies mostly linear algebra as a use case, and a > quick google search ends up with the same thing. So on a value-effort > graph, I think P0672R0 has to much effort for too little value. Attributes > do not change the core language significantly, do not introduce new syntax > or complexities, they simply tell compilers to emit warnings under certain > conditions. That seems like a much cheaper way of getting some safety into > the use of expression templates. It does not allow the drop-in replacement > of expression templates, but I consider that a somewhat minor problem > compared to the bugs that crop up when using them in an auto-riddled, > modern-C++ world. > I think there are a few operations that may be indicative of problem with delayed evaluation/proxy types: copy/move discard (I'll vaguely throw non-dependent operator void() out there) reference binding A temporary bound to a reference such that the reference extends the lifetime of the temporary is a potentially problematic case that you may want to consider with regards to the attributes you are proposing. > > I am not an expert on the standard, so I would love some comments on this. > -- 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/55c9a427-37c7-4a22-8e8a-8c5f00059852%40isocpp.org. ------=_Part_3329_2126778946.1539918763381 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, October 16, 2018 at 4:44:22 AM UTC-4, Till Hei= nzel wrote:
I have previously worked a lot with expression templates, and using them= together with auto is a pain - errors crop up all the time, and I ended up= wrapping most of the functionality away.

= So instead, I would propose adding a new attribute [[temporary_type]] that = tells the compiler to emit a warning when an object of the type is used in = a non-temporary context. I am not too certain on value categories, but I th= ink it would work well if this would just mean a warning when the object is= an lvalue. The user then knows to call some function, or to use a cast or = an explicit type for the assignment, whatever works in the context of the l= ibrary.
An accompanying attribute could be [[allowed_tempora= ry_lvalue]], to suppress the warning at the call site. This would allow usi= ng the type warning-free within the library where it is created, and clearl= y express that this is a special case, not the primary use case for this ty= pe.

While I find P0672R0 interesting, I also = think it may be overkill for a relatively niche problem. I ran into it usin= g armadillo (linear algebra), the Wikipedia site specifies mostly linear al= gebra as a use case, and a quick google search ends up with the same thing.= So on a value-effort graph, I think P0672R0 has to much effort for too lit= tle value. Attributes do not change the core language significantly, do not= introduce new syntax or complexities, they simply tell compilers to emit w= arnings under certain conditions. That seems like a much cheaper way of get= ting some safety into the use of expression templates. It does not allow th= e drop-in replacement of expression templates, but I consider that a somewh= at minor problem compared to the bugs that crop up when using them in an au= to-riddled, modern-C++ world.
I thin= k there are a few operations that may be indicative of problem with delayed= evaluation/proxy types:
copy/move
discard (I&#= 39;ll vaguely throw non-dependent operator void() out there)
reference bindi= ng

A temporary bound to a reference such that the = reference extends the lifetime of the temporary is a potentially problemati= c case that you may want to consider with regards to the attributes you are= proposing.
=C2=A0

I am not an e= xpert on the standard, so I would love some comments on this.

--
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/55c9a427-37c7-4a22-8e8a-8c5f00059852= %40isocpp.org.
------=_Part_3329_2126778946.1539918763381-- ------=_Part_3328_1190624742.1539918763381-- .