220 39542 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Extension methods with a restriction to make it viable Date: Sat, 4 Aug 2018 12:33:12 +0100 Lines: 586 Approved: news@gmane.org Message-ID: References: <7ce23f53-d00e-45a0-a62b-c42060c5833d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000868a505729a6a53" X-Trace: blaine.gmane.org 1533382288 1616 195.159.176.226 (4 Aug 2018 11:31:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Aug 2018 11:31:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDRYVJ6TVYBRBDU6S3NQKGQE54OCFMY@isocpp.org Sat Aug 04 13:31:24 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f199.google.com ([209.85.208.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1flumK-0000KI-9b for gclcip-std-proposals@m.gmane.org; Sat, 04 Aug 2018 13:31:24 +0200 Original-Received: by mail-lj1-f199.google.com with SMTP id z24-v6sf1654672lji.16 for ; Sat, 04 Aug 2018 04:33:35 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1533382415; cv=pass; d=google.com; s=arc-20160816; b=iGpn1a+PEPV7AQoZRRVjtvH4k6YHp99gOkSuSHE0lfufFt8ldJWqCJwYVMYnDpwkK8 F6Od8qqXRsw+IFZgHt9Sq7mRVWNRNt9jqbvMY4G7GxXca2TAZ7y+lYCaWn10yhQubejh 6Z0+6O9XMY18EdmEuFNhY2SCBuL8iFFl25/UWdAAdkLGuG72bCy9l5xibtY7vouZm9pZ jixJGXMExSCKGarDtLGhl1LUw4gWVlMCfKKmqZ5u6bwd827YHY6De3PVY+YVG/KJord5 /BDCyo92C3E5da9G82MytXY3Mgw1BqkNot/pROJHNKC6kJf5wq0TrEPggFKlFex7XI1l GqHQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=dvzRyAqMhP4gVq/Z7YEbbKS8zBeHy1yT+PezopzbSIY=; b=xiH/+wovp2GtZpDeIzRzqVfEHGTT5aLc0anLR89yNTBgZRvoFskI12Fs6g16/Z9kBP MtnihpbGQFWMuepnXbLE8eEm2CUlRxFXcTcURQb7diLKfQ1q/cA56dL+W0pCJ7UIhZzd rOf8fqT/3MPeDWAwbi2IOSyQHoFY3yRKbfmT+qGjsfrhXV8uTq2L4rKJBjkVaiN50N/9 xxg7/laTYGzLfYjh86SXOt0kBxO+s8tCLGGJ3XMQcE4CmkfLVj7MP7YqfdWv7tdnAhwL lalTipc2cxDPKW3VJaASvz4mA6UH9VifIqHot0MRv2ETraCsAktxKH3RwZpGj9eB6wf3 YF/Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OdgAiGHE; spf=pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gasper.azman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=dvzRyAqMhP4gVq/Z7YEbbKS8zBeHy1yT+PezopzbSIY=; b=Wnug2C44hpgq6nhNhQbHWiJ/Y2qirA9YZ6hucSvdlgBG4QcijOCqKwzNeZ5v0dVrLT TbFuAOFJQ2i6Rf1v0jcnK5r8b/l2kF0ZIxtihseLpu4yxgJmdAJ+FjGI5WRdDC9l8U9q o9vkMbk23v37zjaMqjtC2T1zWmE+/IHkscvMZ0MQ8JUQXHAuJjkKsT+ly3mHRzPQMhW6 kgOMuakbTaVonIirgzIgNeNCiwXBFNwFt7N4+ipZqnBON3zsn3oMuvb9sf6V2uUEvaMB YHEPP6c43J3teqornujsHAVxm591nTg7b/6PD/JxDvUwvHVecGXu/4XPyQsTmqk2Co6P GfMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=dvzRyAqMhP4gVq/Z7YEbbKS8zBeHy1yT+PezopzbSIY=; b=Oxh7dWRtehJ4rDd/fCAgYN4pMLcwlVjgVuDb+DpNNrU5VEFxJctPvJVbRK+KoJYYAl 1yXaa79gnKb29lc9uwjPB2yzKlUK3Y8OlIGZnNws1xIpHApC3QnxMErxxy3AWVaWNERd HQqJ7Uk7z0cqMTHylm0Pq2qydiofUhOo8Wau18GBszb05VAS4x84yI7x/Omh4ZHqlf6m mbsUX85IqKTl/Gqnbe4F0wIskx2gEmombTG+6do1hjtVB6r7i3EOeJxpt5fZbkwaNWrU h0+jJfYcd4sU+92muWrroEw4rx0KnnILQTIT8p1buxEDEU1ejZvM7/v0Ol9HvSXCUpxl Ts4g== X-Gm-Message-State: AOUpUlFWnuDYk1Fh45IeHFnpUlBzubN6EJkbFSGghM72LB4ulzmuQKa9 +bOdsJnscppPBsP5cdM/fCEm7w== X-Google-Smtp-Source: AAOMgpcOnoe3sRyeFd1KDWKnvXB1n1WxltLtH/I3A1DjKstUF6ogFKmqlD9eNlxqg+oDM3+06t+yPw== X-Received: by 2002:a2e:850e:: with SMTP id j14-v6mr512476lji.30.1533382415169; Sat, 04 Aug 2018 04:33:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a2e:87c7:: with SMTP id v7-v6ls778013ljj.7.gmail; Sat, 04 Aug 2018 04:33:33 -0700 (PDT) X-Received: by 2002:a2e:96d8:: with SMTP id d24-v6mr8685906ljj.50.1533382413516; Sat, 04 Aug 2018 04:33:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533382413; cv=none; d=google.com; s=arc-20160816; b=Py4dvyFaTpTR6u3A4vCZ0+YaMZNjx3AU4WYbiQQ0DtKHdTQWPlH+csvBWIQGcALS5v LYj89jwo6y+OfENd22ZnQkkBGtcuKwsyzoMkMwXDcMcZNC6X9dU6ZYnSxeYhmTtJ3WyH lnzFcltier9F9zOPIZQxgPYZU3cErRKTZF5Wbjao3U4kOAIblo1IrXvW1SC1M6ArzRVx rqE8xQt8hVu/kK8dLy3eb2hsQ6QKmrfe7UqLPRZBmb7820U7/nnsrCTNg0BpDUBmqxSo uULFORjoZrxWyafyyTuT+knRNRrCkwd6zpSaGqQWopG5xOvX6l2jW+wAFvRnf+N/v2yq +pKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=AsBL9oM8PtORO5S7eLSVbiZWrlTIlMlxETsATiBAPrQ=; b=dQU91makWE4E32qTyQpvG5XNHTJsVnWfpJ4J05bU/PncR0GwnWYWLIRpa404nM9/CH 1JCtNARljAt9Yvc6ZN6zOmUQnoWNpY7u2BF7FGFSzrHN0V0nXqHiBGQjLCAtZ4X2VojG w7thP0hd5OmSyHhheZuWc5m8KZTNDj3jzfp0m/gZXsv2cc0PO7FR8b732ABkuxwAXNGl tJmocDUIdcNqsMyO0dDpzF1q8e9xVDR2un1y6RX5QOmJvPKDWFGRXyLoC+x/gepmo6GQ dT65pmrRz0JAFFcwtFnJnUq2PcaLbqNaw6lt96GJJ+XhW0QpOGdyaQSKJiFjgbCH8v+E /TmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OdgAiGHE; spf=pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gasper.azman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id u12-v6sor1549205ljh.65.2018.08.04.04.33.33 for (Google Transport Security); Sat, 04 Aug 2018 04:33:33 -0700 (PDT) Received-SPF: pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a2e:869a:: with SMTP id l26-v6mr8453636lji.48.1533382413017; Sat, 04 Aug 2018 04:33:33 -0700 (PDT) Original-Received: by 2002:ab3:416:0:0:0:0:0 with HTTP; Sat, 4 Aug 2018 04:33:12 -0700 (PDT) In-Reply-To: <7ce23f53-d00e-45a0-a62b-c42060c5833d@isocpp.org> X-Original-Sender: gasper.azman@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OdgAiGHE; spf=pass (google.com: domain of gasper.azman@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=gasper.azman@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:39542 Archived-At: --0000000000000868a505729a6a53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, I'm posting just to say I will address this as I come back from holiday, in about a week and a half. It's a very interesting take - but needs more careful consideration than I can afford right now. Thanks for your mention! Ga=C5=A1per On Sat, Aug 4, 2018 at 7:25 AM, Justin Bassett wrote: > Seeing as the trailing version of UFCS will never happen (x.foo() meaning > foo(x)) due to the API compatibility nightmare it creates, I would like > to resurrect extension methods. > > Extension methods are clearly very desired, seeing as it has been brought > up many times: > > - Have "extension methods" been proposed for C++1y? (or any previous > standard) > > - Extension methods for C++ > > - extention methods or UFCS > > [sic] > - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0079r0.pdf > > The API compatibility problems arise by allowing extension methods to be > added by the user rather than restricting them to the library author. I > propose adding extension methods, but restricting them such that only the > library author can add them. > > > Currently, postfix function calls are restricted to member functions or > imitated via operator overloading like Ranges. Both of these solutions ha= ve > their problems: > > - Member functions apply only the the specific type. If I write > `Foo::member_function()`, it can only be called on objects of type `Fo= o`, > not of type `Bar`. If I want to be able to call it on `Bar`, I need to= do a > lot of work to make it scale to the other types in the library > - Member functions can't be extended by users of the library. Using > Ranges as an example, the user can't add `my_fancy_algorithm()` as a m= ember > function. > > Concerning Ranges pipe operator: > > - It would be harder to produce good intellisense for | as contrasted > with . , as there are more things to potentially consider. > - Possible affect on compile times (not measured, this can also be > completely wrong) > - Each member of a chain has to be namespace qualified: myRange | > ranges::transform(...) | ranges::accumulate(...) . Using declarations > are not a viable solution; it's too much to require a using declaratio= n for > each function. Using directives are glob imports, so they come with al= l the > problems of glob imports. > - There's a wtf moment for someone unfamiliar with this usage of the > bitwise or operator. Once taught to think about it as a unix pipe, one= can > be more comfortable with it, but personally I've never grown fond of i= t. > > Note: I am using Ranges as an example, but that doesn't mean I think that > Ranges should be delayed. I just think it makes for good examples. > > I much prefer reading myRange.transform(...).accumulate(...), but I > recognize that using member functions just doesn't work here. That's why = I > claim that extension methods are a better solution. > > > With extension methods, I can write myRange.transform(...).my_ > fancy_algorithm(...).accumulate(...) rather than myRange | > ranges::transform(...) | my_ns::my_fancy_algorithm(...) | > ranges::accumulate(...) > > The biggest caveat of extension methods is that library authors lose > control over what can come after the . . As a preliminary proposal on a > restriction that restricts extension methods to library authors, let's > choose the restriction that extension methods must be findable via ADL. > Further, to avoid conflicts with free functions, let's consider all > .foo(...) functions (whether member or extension methods) separate from > free functions when performing overload resolution. > > Arbitrary syntax (considering the "deducing this" proposal, this should > probably mimic the syntax decided for that): > > namespace ns::ranges { > > struct adl_tag {}; > > template > struct view { > auto begin() const; > auto end() const; > // ... > }; > > // ... > > template > auto transform(T&& this self, F&& fn) { > // ... > } > > // ... > > } > > // Usage: > > ns::ranges::view(myRange) > .transform(...) > .accumulate(...); > > // Extending with my own algorithms: > > namespace user { > > template > struct my_view > : private ns::ranges::adl_tag // allow ADL to look into ns::ranges > { > // ... > }; > > template > auto my_fancy_algorithm(T&& this self, F&& fn) { > // ... > } > > } > > // Usage: > > user::my_view(myRange) > .transform(...) > // Barring type erasure, we can still find my_fancy_algorithm since > the > // user::my_view type is encoded into the template type somewhere > .my_fancy_algorithm(...) > .accumulate(...); > > > Problems that have yet to be addressed: > > - In the definition of a class method, does this->foo(...) consider > extension methods in overload resolution? Why or why not? > - Outside of the definition of a class method, does foo.bar(...) > consider both extension methods and member functions in overload > resolution? Why or why not? (I think it should overload both; if the m= ember > function doesn't exist, it should be able to fall back on extension me= thods) > - Should qualified function calls be allowed? That is, should I be > able to write foo.std::ranges::transform(...)? This would be > consistent with member functions; I can already write > string.std::string::size(). If we allow this, should this be able to > call extension methods from arbitrary namespaces, not just ones that c= an be > found via ADL? > - Is this a reasonable restriction level? If the library implementer > does not put all the extension methods in their own namespace with a > wrapper that brings them into context, it could get out of hand fast. > Granted, this would be no different from using unqualified prefix func= tion > calls. > > -- > 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/7ce23f53-d00e-45a0- > a62b-c42060c5833d%40isocpp.org > > . > --=20 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 e= mail 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/CAANG%3DkVgcf9o1K8dGVKj4_ECQRC_UmJXB%3D_NFOo%3DL= ymMMsP6yQ%40mail.gmail.com. --0000000000000868a505729a6a53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

I'm posting just to say = I will address this as I come back from holiday, in about a week and a half= .. It's a very interesting take - but needs more careful consideration t= han I can afford right now.

Thanks for your mentio= n!

Ga=C5=A1per

On Sat, Aug 4, 2018 at 7:25 AM, Justin Ba= ssett <jbassett271@gmail.com> wrote:
Seeing as the trailing version of UFCS will= never happen (x.foo() meaning= foo(x)) due to the API compat= ibility nightmare it creates, I would like to resurrect extension methods.<= div>
Extension methods are clearly very desired, seeing as it= has been brought up many times:
The API compatibility problems ari= se by allowing extension methods to be added by the user rather than restri= cting them to the library author. I propose adding extension methods, but r= estricting them such that only the library author can add them.
=


Currently, postfix function calls are restricted to= member functions or imitated via operator overloading like Ranges. Both of= these solutions have their problems:
  • Member functions ap= ply only the the specific type. If I write `Foo::member_function()`, it can= only be called on objects of type `Foo`, not of type `Bar`. If I want to b= e able to call it on `Bar`, I need to do a lot of work to make it scale to = the other types in the library
  • Member functions can't be extend= ed by users of the library. Using Ranges as an example, the user can't = add `my_fancy_algorithm()` as a member function.
Concerning R= anges pipe operator:
  • It would be harder to produce = good intellisense for=C2=A0| a= s contrasted with=C2=A0.=C2=A0= , as there are more things to potentially consider.
  • Possible affect= on compile times (not measured, this can also be completely wrong)
    • Each member of a chain has to be namespace qualified: myRange | ranges::transform(...) | ranges::accumulate(...= ) . Using declarations are not a viable solution; it's too much = to require a using declaration for each function. Using directives are glob= imports, so they come with all the problems of glob imports.
  • There= 's a wtf moment for someone unfamiliar with this usage of the bitwise o= r operator. Once taught to think about it as a unix pipe, one can be more c= omfortable with it, but personally I've never grown fond of it.
Note: I am using Ranges as an example, but that doesn't me= an I think that Ranges should be delayed. I just think it makes for good ex= amples.

I much prefer reading myRange.transform(...).accumulate(...), but I recognize that using member functions= just doesn't work here. That's why I claim that extension methods = are a better solution.

With extension methods, I can write myRange.transform(...).my_fancy_algo= rithm(...).accumulate(...) rather than=C2=A0myRange | ranges::transform(...) | my_ns::my_fancy_algor= ithm(...) | ranges::accumulate(...)

The = biggest caveat=C2=A0of extension methods is that library authors lose contr= ol over what can come after the . As a preliminary proposal on = a restriction that restricts extension methods to library authors, let'= s choose the restriction that extension methods must be findable via ADL. F= urther, to avoid conflicts with free functions, let's consider all .foo(...) functions (whether member or extension methods) separate fr= om free functions when performing overload resolution.

Arbitrary syntax (considering the "deducing this" propo= sal, this should probably mimic the syntax decided for that):
<= div>
na= mespace ns::ranges {
<= br>struct adl_tag {};

template <typename = Range>
struct view = {
=C2=A0 =C2=A0 auto begin() const;
=C2=A0 =C2=A0 = auto end() cons= t;
=C2=A0 =C2=A0 // ...
};

// ...

templ= ate <typename T, typename F>
a= uto transform(T&&<= span style=3D"color:#000" class=3D"m_-7692250097086650299styled-by-prettify= "> this self, F= && fn) {
=C2= =A0 =C2=A0 // ...
}

// ...

}

// Usag= e:

ns::ranges::v= iew(myRange)
=C2=A0 =C2=A0 .transform(...)
=C2=A0 =C2=A0 = .accumulate(...);

// Exte= nding with my own algorithms:

namespace user {

template = <typename Range>struct my_view
=C2=A0 =C2=A0 : = private ns::ranges::adl_tag // allow ADL to look into ns::ranges
{
=C2=A0 =C2=A0 // ...
<= span style=3D"color:#660" class=3D"m_-7692250097086650299styled-by-prettify= ">};

template <= typename T, typename F>
auto my_fancy_algorithm= (T&& this self, F&& fn) {
=C2=A0 =C2=A0 // ...
}

}

// Usage:

user::my_view= (myRange)
=C2=A0 =C2=A0 .= transform(...)
=C2=A0 =C2=A0 // Barri= ng type erasure, we can still find my_fancy_algorithm since the=C2=A0 =C2=A0 //=C2=A0user::my_view type is encoded=C2=A0into the templ= ate type somewhere
=C2=A0 =C2=A0 .my_fancy_algorithm(= ....)
=C2=A0 =C2=A0 .accumulate(.= ...);
<= br>

Problems that have yet to be addressed:
  • In the definition = of a class method, does this-&= gt;foo(...) consider extension meth= ods in overload resolution? Why or why not?
  • Outside of the definition of a class method, does <= font face=3D"courier new, monospace">foo.bar(...) consider both extension methods and member functions in over= load resolution? Why or why not? (I think it should overload both; if the m= ember function doesn't exist, it should be able to fall back on extensi= on methods)
  • Should qualifie= d function calls be allowed? That is, should I be able to write foo.std::ranges::transform(...)? This would be consistent with member f= unctions; I can already write = string.std::string::size(). If we a= llow this, should this be able to call extension methods from arbitrary nam= espaces, not just ones that can be found via ADL?
  • Is this a reasonable restriction level? If the libra= ry implementer does not put all the extension methods in their own namespac= e with a wrapper that brings them into context, it could get out of hand fa= st. Granted, this would be no different from using unqualified prefix funct= ion calls.

--
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-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/7ce2= 3f53-d00e-45a0-a62b-c42060c5833d%40isocpp.org.

--
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/CAANG%3DkVg= cf9o1K8dGVKj4_ECQRC_UmJXB%3D_NFOo%3DLymMMsP6yQ%40mail.gmail.com.
--0000000000000868a505729a6a53-- .