220 32056 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proxy objects and casting to rvalues Date: Sun, 9 Apr 2017 07:30:28 -0700 (PDT) Lines: 128 Approved: news@gmane.org Message-ID: References: <9da2eb61-ab97-4b03-933e-da18139d77c0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5456_1052885705.1491748228687" X-Trace: blaine.gmane.org 1491748243 12826 195.159.176.226 (9 Apr 2017 14:30:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 9 Apr 2017 14:30:43 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBBMLVHDQKGQEOJ3UH5Y@isocpp.org Sun Apr 09 16:30:38 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f200.google.com ([209.85.213.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cxDrE-0001bo-OF for gclcip-std-proposals@m.gmane.org; Sun, 09 Apr 2017 16:30:24 +0200 Original-Received: by mail-yb0-f200.google.com with SMTP id f204sf42248176ybc.13 for ; Sun, 09 Apr 2017 07:30:30 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=HYXLSAz150hibV8svTakclQkPsCbBuDI0CCVRrIyp6A=; b=hpg9BuntCFvpcVdbDbFsBgHvfK1+/FjN85yhdgl+7/orl3JnjSAEsCw7BmytWvCCYq 2cBT8PiOFeWw1qZ3TM6GZ5HBjHhgRLfeYD73b51nbK0JB5oPjP6fMxYKDqbmXw1w3HJp dz1zbHsH5O791cZED1TRhu36IcuSr+rKd6q6RiZCNV4+WbwtH1S7qRnZj1hCTdlhHsG5 /uBI8PcoCjG/AaOHI1I48ysnYA3RGHATAEjnR/eef4cnwSJNQSCnT2eeRA9YTOOHXChD Drxz2zDiLt2Q+8U8j9qKQuC94DZ7Q8GLoM1GlZdyHAoksHxzK8pnWJH2R5yz8csq8iZq gpuA== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=HYXLSAz150hibV8svTakclQkPsCbBuDI0CCVRrIyp6A=; b=ouRPY5/ZrJRKwN3bMz3ttpQuOvkZuWWuaj92fS8w+TVNqre97xs30LeIDYJWM9+5Sa Woyg7a1eNkxpsdWgM+Cbkysx4GcMbryYZ66xshsva7dQRf1quZMBpBKIZ99xo/SEzLoL 6hG0xvsEwAlQahuVEkhS9PQaAKsNmzcVjmhbEtwjAgAQPGy50XuvVYy8XSXPVpHd8s6F O7LXfBu7Q9YGaE7KUW8z17RrB72W9+WA7/rjzw5nPajwQjvvfKfXXnlcNvjmgrWmEQiN rRedJ6/4UqrUMJL9rijQfx1+QIlcfqMHIxCMbS27CgN6EcIO/c37duV31kPcwrtX6oYX EU4A== 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=HYXLSAz150hibV8svTakclQkPsCbBuDI0CCVRrIyp6A=; b=Z4DUIIDhcB5m29kwZZr0lvcANDFfl5La6LpCOv+QD5pbriZCITVfCTQbdS4vgfRCnE CMbIWq3bMzfvdxFptBEo76pkmh80e8Q3pYSSX3v9LH2W1JuoWLS8w4ooZJliXoO2URZ7 mGLwO1kJOhY3dRIVLrv1e8ogAA4Ym/wcjLmxG6/N/1G/6ZpDWdhSuJ0kTnhhyKodOwZp VjI8tuaRU2j5rjTAsGxo3wQp7nOf3sH8v3Dt3qBk2qgOglXXonLeEKJYXAEVdOUoVhiV h/K4UQA/sVciv+YbWmW+pBp7BrCj1Xhcvy1XM/z83LnfYE0NzKnnnfSDUoj1wsMGKvfX hsJg== X-Gm-Message-State: AN3rC/6sHhq49IYKCJdXBS9yOPHqh/gH6aCeq/DNjFYJYG9SA7cy9r0CNi0tdtnw+Bp64w== X-Received: by 10.129.41.9 with SMTP id p9mr4686740ywp.36.1491748230104; Sun, 09 Apr 2017 07:30:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.17.215 with SMTP id y23ls4820528oty.49.gmail; Sun, 09 Apr 2017 07:30:29 -0700 (PDT) X-Received: by 10.157.26.98 with SMTP id u31mr251233otu.0.1491748229107; Sun, 09 Apr 2017 07:30:29 -0700 (PDT) In-Reply-To: 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:32056 Archived-At: ------=_Part_5456_1052885705.1491748228687 Content-Type: multipart/alternative; boundary="----=_Part_5457_97465389.1491748228688" ------=_Part_5457_97465389.1491748228688 Content-Type: text/plain; charset=UTF-8 What you're essentially asking is a modified form of something that has been discussed since `auto` came into existence: the ability to specify the type that will be deduced by `auto`. And proxy objects are the primary justification for it, whether it is proxy iterators or lazy evaluation of expressions (you want `auto` to evaluate the lazy expression, not store the lazy intermediate). The best syntactic form I've seen this in is via a member function of the form: class bit_wrapper { public: Typename operator auto() const { } }; Note that this allows you to do arbitrary work in the conversion section. Though we might add an `= default` version which is equivalent to implicit conversion via `return *this;`. This function is put in the actual type that would otherwise be deduced. I think this works much better than your notion of adding it to the `operator*` of the iterator (I assume; you put it in `vector` instead, which has no `operator*`). Your way requires the compiler to change what it is doing based on the return of a specific function call, so it requires more work to do lazy expression evaluation, since you have to apply it to every single function that returns a lazy result. Whereas here, you just apply this to the lazy result *types*, and every use of those types will automatically have this power. The big, unanswered question with such a feature is mainly about what exactly it affects. Does it only affect uses of the `auto` keyword for variables? If it only affects `auto` variables, would that not be strange with regard to generic lambda/Concepts TS `auto` parameters, which use template argument deduction? Does it affect `decltype(auto)`, and if so, how exactly? If it affects every form of deduction (template argument, `decltype(auto)` and `auto`), then exactly how does it work? -- 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/a4e15473-7370-4a69-b126-58c48a64c401%40isocpp.org. ------=_Part_5457_97465389.1491748228688 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What you're essentially asking is a modified form of s= omething that has been discussed since `auto` came into existence: the abil= ity to specify the type that will be deduced by `auto`. And proxy objects a= re the primary justification for it, whether it is proxy iterators or lazy = evaluation of expressions (you want `auto` to evaluate the lazy expression,= not store the lazy intermediate).

The best syntactic form I've = seen this in is via a member function of the form:

class bit_wrapper
{
public:
=C2=A0 =C2=A0 Typename operator auto() const { <conversion expression> }
};

Note that this allows you to do a= rbitrary work in the conversion section. Though we might add an `=3D defaul= t` version which is equivalent to implicit conversion via `return *this;`.<= br>
This function is put in the actual type that would otherwise be dedu= ced. I think this works much better than your notion of adding it to the `o= perator*` of the iterator (I assume; you put it in `vector<bool>` ins= tead, which has no `operator*`). Your way requires the compiler to change w= hat it is doing based on the return of a specific function call, so it requ= ires more work to do lazy expression evaluation, since you have to apply it= to every single function that returns a lazy result. Whereas here, you jus= t apply this to the lazy result types, and every use of those types = will automatically have this power.

The big, unanswered question wit= h such a feature is mainly about what exactly it affects. Does it only affe= ct uses of the `auto` keyword for variables? If it only affects `auto` vari= ables, would that not be strange with regard to generic lambda/Concepts TS = `auto` parameters, which use template argument deduction? Does it affect `d= ecltype(auto)`, and if so, how exactly? If it affects every form of deducti= on (template argument, `decltype(auto)` and `auto`), then exactly how does = it work?

--
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/a4e15473-7370-4a69-b126-58c48a64c401= %40isocpp.org.
------=_Part_5457_97465389.1491748228688-- ------=_Part_5456_1052885705.1491748228687-- .