220 39072 <18726326-2018-49e5-afb9-bfd0ae0937de@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: expression based deduction guides Date: Wed, 11 Jul 2018 00:47:07 -0700 (PDT) Lines: 452 Approved: news@gmane.org Message-ID: <18726326-2018-49e5-afb9-bfd0ae0937de@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_126122_1436810886.1531295227688" X-Trace: blaine.gmane.org 1531295103 15363 195.159.176.226 (11 Jul 2018 07:45:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Jul 2018 07:45:03 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRB7HLS3NAKGQEZ4GBAIQ@isocpp.org Wed Jul 11 09:44:59 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fd9o3-0003sA-8N for gclcip-std-proposals@m.gmane.org; Wed, 11 Jul 2018 09:44:59 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id p11-v6sf24797739ywm.4 for ; Wed, 11 Jul 2018 00:47:10 -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=8bxhsOdzpgdLotkCeyVtxY3mQ1+0FLvz5ZjJB8yr+7w=; b=SCiM3F3KbfjOj75BF/iCdV77OA+jUsmJohybMrHxb9vNvOdolHQeku1HF+4DWC6sjN I6u9YLBC+7gYuYN6poaxPGKiBhT69Q76kB6h+GEMDmCLUqD0LJWytAHk2A5cD6n//DgR O1YTmkqoPO8sBbdJq/AkhBbnvGoCS8tuy4aay4/Pf8m35wcbs95rEU3xYTKG3HM7/gAA 5LtMNFVPyurVIFqLtbcQ5taWl47i4svrSCGZrdz7n1/e7SEGk32gS+jiu6jnrLQODIqS BMZbO/hT8VNuNBEAsEAXh5WZtU4pB4f0fWCencWelas9oPpjexKVOUWZtPKCyDBl68NA MoOQ== 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=8bxhsOdzpgdLotkCeyVtxY3mQ1+0FLvz5ZjJB8yr+7w=; b=UJnJnMYlsFvhjIDYYdUfF+aMvnmZTIl+Rxw4MPvr/O2bqykVoqxNH6CoE8/p/iW3SM GW6CcZDmSbFD/BFK8ikEfoYuu8gILUIYdpsfBB4LiXKuAg9p7zRf2/pKu+qKW0OwkWQy 9LISBCEZY4F0QzpqXzeL4Av+QVIMSrKXe28gXUWfLB8EipO5NkvqYHGNzmiUsYiqrsxy Rv6rRtp2eu9EZmQKk0WLCfV53fn9cDfGS5nYb8NXwYDF1XoW/isY5FfkT0cZgA2VX3mT j2EgKbkpt+VE3q+lhJUUyA0c9ebzrPlWdRfZMlxkl8kfUIq+rqoeilbmzD7VI3zNIAAs vJBA== 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=8bxhsOdzpgdLotkCeyVtxY3mQ1+0FLvz5ZjJB8yr+7w=; b=VyxmaUASIAZTs4MXrPDgNBfSYYGg4v8V0vmoUYq9F5ddS7Pf1rcDJh5W3SYJVp+9V8 qs659Zfdq7Mhyu2v9Be7e6U32k343tdIBd5wNcaTvS5WVqnxh6MO/w9DHeroXERS/kBh So/6MherDEWlj5Ev+S2Npty00SknRA4K+vkXLZebmE5+yurmZ2yoD3dp1PhOiT/CyiVj DmUu8l5W2XeIN3DSIuIBx9hJ5P9BIKkC/BTAjYcybRi0AHhCu5oIN12sGc+7kotooc0v oWHZa4USeEgKfIUt7ePL84PUqfBeGZGq+h4RlPHsOFL4IPsDmEt6uvTWn/8xuV6qfXmJ mTZg== X-Gm-Message-State: APt69E266noByz7+Ez6gYdQJAcz2uapFosPtR6tt7ETI3VL9ZSHKb8+9 jWMl7VlGWf73Ldmw0bOI5Ck0QA== X-Google-Smtp-Source: AAOMgpf1xHAJ8CQb7/QQYnzbcAKYOMsRI0+pDtmHSH8DkUzUOjADpJ6wyj73rJVkgBZHnm9Ebgnubg== X-Received: by 2002:a0d:d790:: with SMTP id z138-v6mr8222930ywd.194.1531295229622; Wed, 11 Jul 2018 00:47:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:7a4e:: with SMTP id v75-v6ls3015563ywc.12.gmail; Wed, 11 Jul 2018 00:47:08 -0700 (PDT) X-Received: by 2002:a81:7dd6:: with SMTP id y205-v6mr3733871ywc.1.1531295228386; Wed, 11 Jul 2018 00:47:08 -0700 (PDT) In-Reply-To: X-Original-Sender: MihailNajdenov@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:39072 Archived-At: ------=_Part_126122_1436810886.1531295227688 Content-Type: multipart/alternative; boundary="----=_Part_126123_1884275506.1531295227690" ------=_Part_126123_1884275506.1531295227690 Content-Type: text/plain; charset="UTF-8" On Wednesday, July 11, 2018 at 3:00:32 AM UTC+3, bastie...@gmail.com wrote: > > Hi, > > Deduction guides are great but could be even better if we were able to > better control the conversion and why not even produce custom conversions. > For instance if you wanted this work: > > std::list y { ... }; > std::vector x { y }; > > you could just write the following to make it work: > > template > std::vector(Container&& t) { return std::vector{t.begin(), t.end()}; } //or > "= expr".The block would be as restrictive as c++11's constexpr functions > > And if those expression where preparsed and injected instead of working > like normal function returns: > > > //Implementing lazy on the library side > template > struct Lazy : public T > { > Lazy(T&& f) : T(std::forward(f)) {} > using T::operator(); > }; > > template > Lazy(T&& x) { return Lazy{[&]{ return x; }}; } //no recursion, uses given > constructor as deduction guide > > > template > void func(Lazy x) > { > x(); > x(); > } > > int f() > { > std::cout << "hello" << std::endl; > return 0; > } > > int main() > { > func(f()); //func(Lazy{[&]{return f(); }}); > } > > //Implementing overload set as arguments by allowing unresolved types to > be passed to OverloadSet before error > template > struct OverloadSet : public T > { > Lazy(T&& f) : T(std::forward(f)) {} > using T::operator(); > }; > > template > OverloadSet(T&& x) > { > return OverloadSet{ > [](Args&&... args) > noexcept(noexcept(x(std::forward(args))) > -> decltype(x(std::forward(args)) > { > return x(std::forward(args)); > } > }; > } > > int f() { return 0; } > int f(int) { return 0; } > > template > void func(T&& x) > { > x(0); > x(); > } > > int main() > { > func(f); /* func(OverloadSet{[](Args&&... args) > noexcept(noexcept(x(std::forward(args))) > -> decltype(x(std::forward(args)) > { > return x(std::forward(args)); > }); */ > } > > This would allow to have a real C++ alternative to long expression, type > conversions macros. > Just a thought, what do you think? > Anyway thanks for the read. > So basically, these are external constructors. My gut feeling tells me, these were considered and rejected (postponed?). Needless to say all is possible if you make these plain old functions - auto lazy(. . . ), auto OverloadSet(. . .) Granted in the overload set case you will lose the implicit conversion. And BTW there is no reason for these to be constexpr - they simply need to return the correct type . However, I see no reason recursion NOT to be a problem. But that is solvable template Lazy(T&& x) { auto t = [&]{ return x; }; return Lazy{std::move(t)}; *//< ### deduction guides IGNORED if explicit type is specified * } As I said, I am pretty sure this was considered - there is no way not to have been, considering deduction guides look exactly like constructor-returning-a-type. I just does not have a body... yet? -- 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/18726326-2018-49e5-afb9-bfd0ae0937de%40isocpp.org. ------=_Part_126123_1884275506.1531295227690 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wednesday, July 11, 2018 at 3:00:32 AM UTC+3, b= astie...@gmail.com wrote:
Hi,

Deduction guides are great bu= t could be even better if we were able to better control the conversion and= why not even produce custom conversions.
For instance if you wan= ted this work:

std::list<int> y = { ... };
std::vector<int> x { y <= span style=3D"color:#660">};

y= ou could just write the following to make it work:

template<Container T>
std<= /span>::vector= (Contai= ner&& t) { return st= d::vect= or{t.begin(), =C2=A0t= .end()}; } //or "=3D expr".The block would be as res= trictive as c++11's constexpr functions
= =C2=A0
And if those expression where preparsed a= nd injected instead of working like normal function returns:
=C2=A0

//Implementing lazy on= the library side
template<class T>
struct Lazy : public T
{
=C2=A0 =C2=A0 <= /span>Lazy(T&&= ; f) :<= span style=3D"color:#000"> T(std::forward<T>(f)) {} =C2=A0 =C2=A0
=C2=A0 =C2=A0 using T::operator();
};

template<class T>
Lazy(T&& x) { retu= rn Lazy{[&]{ return x; }}; } //no recursion, uses given constructor as d= eduction guide

=C2=A0
template<class T>
void func(Lazy<T> x)
{
=C2=A0 =C2=A0 =C2=A0= x();=C2=A0 =C2=A0 =C2=A0x();
}

int f()
{
=C2=A0 =C2=A0std::cout <&= lt; &qu= ot;hello" << std::endl;
=C2=A0 =C2=A0return 0;
}

int main()
{
=C2=A0 =C2=A0func(<= /span>f()); //func(La= zy{[&]{return f(); }});
}

//Implementing overload set as arguments by allowing unreso= lved types to be passed to OverloadSet before error
template<class T>
struct OverloadSet : public T
{
=C2=A0Lazy= (T&& f= ) : T(std::forward<T>(f)) {}
=C2=A0using T::operator();
};

template<class T>
OverloadSet= (T&= & x= )
{<= /span>
=C2=A0return OverloadSet{
=C2=A0 []<class... Args>(Args&&... args)
=C2=A0 = =C2=A0 =C2=A0noexcept(noexcept(x(std::forward<Args...>(args)))
=C2=A0 =C2=A0 =C2=A0-> decltype(x(std::forward<Args...>(args))
=C2=A0 =C2=A0{=
=C2=A0 =C2=A0 =C2=A0return x(std::forward<Args...>(args));
=C2=A0 =C2=A0= }
= =C2=A0};
}<= br>
int f()= { return 0; }
int f(int) { return 0; }<= /span>

= template<class T>
void func(T&& x)
{
=C2=A0x(0);
=C2=A0x();
}

int main()
{
=C2=A0func(f); /* func(OverloadSet{[]<class... Args>(Args&&.= ... args)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 noexcep= t(noexcept(x(std::forward<Args...>(args)))
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -> decltype(x(std::forward<Arg= s...>(args))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return x(std::for= ward<Args...>(args));
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0}); */
}

This would allo= w to have a real C++ alternative to long expression, type conversions macro= s.
Just a thought, what do you think?
Anyway thanks for= the read.


So ba= sically, these are external constructors. My gut feeling tells me, these we= re considered and rejected (postponed?).

Needless to say all = is possible if you make these plain old functions - auto lazy(. . . ), auto= OverloadSet(. . .)
Granted in the overload set case you will los= e the implicit conversion.=C2=A0


And BTW t= here is no reason for these to be constexpr - they simply need to return th= e correct type .

However, I see no reason r= ecursion NOT to be a problem. But that is solvable

template<class T>
Lazy(T&& x)=C2=A0<= br>
{=C2=A0
=C2=A0 auto t =3D=C2=A0[&]{ return x; };
=C2=A0 return Lazy<declty= pe(t)>{std::move(t)}; //< ### deduction guides IGNORED if explicit= type is specified=C2=A0
}

=C2=A0As I said, I am pretty sure this was= considered - there is no way not to have been, considering deduction guide= s look exactly like constructor-returning-a-type.=C2=A0
I just do= es not have a body... yet?

--
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/18726326-2018-49e5-afb9-bfd0ae0937de= %40isocpp.org.
------=_Part_126123_1884275506.1531295227690-- ------=_Part_126122_1436810886.1531295227688-- .