220 32336 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: =?UTF-8?B?UmU6IFtzdGQtcHJvcG9zYWxzXSBSZTogQWRkaW5nIHRoZSBLZXl3b3JkIOKAnGludGVyZg==?= =?UTF-8?B?YWNl4oCdIGluIEMrKw==?= Date: Mon, 8 May 2017 08:16:23 -0700 (PDT) Lines: 123 Approved: news@gmane.org Message-ID: References: <9ee212eb-4037-40c4-94c3-57a9a170a4c3@isocpp.org> <1765502.4y06pMOS3s@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3882_756654383.1494256584134" X-Trace: blaine.gmane.org 1494256586 27129 195.159.176.226 (8 May 2017 15:16:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 May 2017 15:16:26 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBSEXYLEAKGQEYWYV3XA@isocpp.org Mon May 08 17:16:21 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d7kOb-0006xE-AE for gclcip-std-proposals@m.gmane.org; Mon, 08 May 2017 17:16:21 +0200 Original-Received: by mail-oi0-f69.google.com with SMTP id d142sf17639324oib.7 for ; Mon, 08 May 2017 08:16:27 -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=Ixv5Ueutc0p0yIkDv9LWN6OOUdYTXwqvLtqrzBrj/dU=; b=sr+NCCYyEQCX0i/CsLjDh88bTUvwWYOzl4jgW2XRyWsomfepugwFmb6pjg2VELJ3nF 2v2TeV2qfoNFK4/Qktp0XZ3GvIe2VzODzqTF7HrUaGKBuWwqTJS33jwjk4252sgBnI4k 534qNak8tMN+n8ccYYck1xzeYMzj5qqll94hVCOQkSt7K2Wtan3P9uQBiSEYts55h8PS fCu89PfpLasJkwgudlk8APUqSoLI6x9VNAT1ez+DpsPVyP7U+oTKRV2Rot3NTuWTKob7 SyQVnP/cunhMAGp/CmD7GjrUGNxipD9CrwB6YeuByhDJwwOZV1RVxxUmTBusvQ9Y5cE1 8Plg== 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=Ixv5Ueutc0p0yIkDv9LWN6OOUdYTXwqvLtqrzBrj/dU=; b=cf8T6Tg300dsGgGWCJJh6GFwjMX4SXREELiZWLaQ2GV5AUQMy25002b7bGwgOuF2pV ypCnP7amatzDWWfs+FxiChXHdtoRyEl7plXRMFW4VDZV6dNkT4vTfWQywBcZMpjV9cek mA3pRgqZnWLNvVF+d1PtaMr4SvdwBV4pkvVBNdO6FD8LeRsEqFM5hXR62mj3RiGnD7Ls olFcaBUYcpHmvFDv8w2PvIxUalQevcIx9f4vMFlrKioTQYYVc9/WCfuQkA4uj9jHOSV2 +7UOFj1CPUe0h6LcDSRZi7ZbOW1zNyaOBhXgoPPUE04wN1Zf46pEEUCFdLOC/NDR9Vgo mVxQ== 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=Ixv5Ueutc0p0yIkDv9LWN6OOUdYTXwqvLtqrzBrj/dU=; b=WExIw8MIsjX4rzaeFUpgBUwxlxpT0vJtohmlP1UA3zyEZ6tpu+pJ6QAnRVtNRliTeY ZqSeE+Q/TWznU39i5f3WyeIAh+0LgBGOOC1AQyUdSKX105DEWAY5xpZMacjPQCCaE8XH gGjr/MkwAUngqlzIzThnYlrtdz3F8UKVd0vpPCS4ObE0cIEGtQ2K+RncqKfBqJjFtkD2 R4BK1F1aKZUeixWy6neA8XpxCmgkzudNEqaufK2goLODR/SNKeqqQLAFalCP3dB2TDPp WuOD0yQFAFYmDRFP0/xtH/DCuIfU+YoD1nLom24403MNBaDIkJXaH3fV/f9L5X5e25eX j7EQ== X-Gm-Message-State: AN3rC/4fNlnwSmWDu4pW8blt62WZXAZVMRvLCtH7j840sRzDG0qJEa8F lHcLTScfHWwDmQ== X-Received: by 10.157.29.240 with SMTP id w45mr25630701otw.56.1494256586609; Mon, 08 May 2017 08:16:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.47.99 with SMTP id h90ls9968875otb.38.gmail; Mon, 08 May 2017 08:16:24 -0700 (PDT) X-Received: by 10.157.45.132 with SMTP id g4mr1263484otb.0.1494256584683; Mon, 08 May 2017 08:16:24 -0700 (PDT) In-Reply-To: <1765502.4y06pMOS3s@tjmaciei-mobl1> 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:32336 Archived-At: ------=_Part_3882_756654383.1494256584134 Content-Type: multipart/alternative; boundary="----=_Part_3883_1322722543.1494256584134" ------=_Part_3883_1322722543.1494256584134 Content-Type: text/plain; charset=UTF-8 On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Macieira wrote: > > On Monday, 8 May 2017 00:30:58 PDT Mingxin Wang wrote: > > Unlike the "*Concespts*" that work at compile time, the > > "*Interfaces*" work at runtime mostly. In essence, it is not only > > a syntactic sugar, but a style of implementation for *polymorphism*: > > virtual functions are only generated when required at runtime > > "virtual functions generated at runtime" needs A LOT of explanation. > Please > explain how the compiler would implement such a thing. > > i also recommend finding another name for your feature. "interface" is a > widely > known term and means something else: it means a base class with virtuals > that > need to be overridden. > I think the idea that he's trying to get across is the following. An `interface` is a class which is implicitly convertible from any type which matches some concept. The implicit conversion effectively works by storing a type-erased pointer/reference to the object it is converted from. The concept it matches is defined by the set of member functions in the `interface`. The `interface` class will automatically generate matching member functions which forward calls to the type-erased pointer/reference. So it's not a "virtual" call in the language sense; it's a virtual call in the polymorphic sense. I like the idea of being able to take a concept and turn it into a type that can type-erase any type that matches the concept. This allows you to turn a compile-time polymorphism tool into a runtime polymorphism tool. But if you want to do it directly through concepts, then this should include more than just member functions. The type-erasure/code generation now needs to include any operations specified by the concept, including overloaded operators, global ADL functions, and the like. I would also want to see some way of defining copy/move behavior. That is, whether the conversion to the "interface" type will create its own object (like `any` or `function`) or whether it will just reference an existing one, as well as specifying whether the type is move-only or copyable. -- 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/e8fb03f4-8c94-46c2-a612-acab81117998%40isocpp.org. ------=_Part_3883_1322722543.1494256584134 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Monday, May 8, 2017 at 10:54:13 AM UTC-4, Thiago Maciei= ra wrote:
On Monday, 8 May 2017= 00:30:58 PDT Mingxin Wang wrote:
> Unlike the "*Concespts*" that work at compile time, the
> "*Interfaces*" work at runtime mostly. In essence, it is= not only
> a syntactic sugar, but a style of implementation for *polymorphism= *:
> virtual functions are only generated when required at runtime

"virtual functions generated at runtime" needs A LOT of expla= nation. Please=20
explain how the compiler would implement such a thing.

i also recommend finding another name for your feature. "interface= " is a widely=20
known term and means something else: it means a base class with virtual= s that=20
need to be overridden.

I think the idea that h= e's trying to get across is the following.

An `interface` is a c= lass which is implicitly convertible from any type which matches some conce= pt. The implicit conversion effectively works by storing a type-erased poin= ter/reference to the object it is converted from.

The concept it mat= ches is defined by the set of member functions in the `interface`. The `int= erface` class will automatically generate matching member functions which f= orward calls to the type-erased pointer/reference.

So it's not a= "virtual" call in the language sense; it's a virtual call in= the polymorphic sense.

I like the idea of being able to take a conc= ept and turn it into a type that can type-erase any type that matches the c= oncept. This allows you to turn a compile-time polymorphism tool into a run= time polymorphism tool. But if you want to do it directly through concepts,= then this should include more than just member functions. The type-erasure= /code generation now needs to include any operations specified by the conce= pt, including overloaded operators, global ADL functions, and the like.
=
I would also want to see some way of defining copy/move behavior. That = is, whether the conversion to the "interface" type will create it= s own object (like `any` or `function`) or whether it will just reference a= n existing one, as well as specifying whether the type is move-only or copy= able.

--
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/e8fb03f4-8c94-46c2-a612-acab81117998= %40isocpp.org.
------=_Part_3883_1322722543.1494256584134-- ------=_Part_3882_756654383.1494256584134-- .