220 39036 <41949fb9-c3b6-4d16-a760-2d9064bce683@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Strong named arguments as tag overloads Date: Mon, 9 Jul 2018 11:56:27 -0700 (PDT) Lines: 546 Approved: news@gmane.org Message-ID: <41949fb9-c3b6-4d16-a760-2d9064bce683@isocpp.org> References: <45cdc03c-1370-4ac3-a8ff-334dcc8884b3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_110958_324298937.1531162588126" X-Trace: blaine.gmane.org 1531162471 21248 195.159.176.226 (9 Jul 2018 18:54:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Jul 2018 18:54:31 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBXO7R3NAKGQERYTRPYY@isocpp.org Mon Jul 09 20:54:27 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fcbIm-0005Ml-Mi for gclcip-std-proposals@m.gmane.org; Mon, 09 Jul 2018 20:54:25 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id c11-v6sf20304122ywb.0 for ; Mon, 09 Jul 2018 11:56:36 -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=SSozHCnZ47dgg+OhQOllMO1QAv6/Es62fq7RpKKqJSw=; b=0yT2bIxNxWGnA1wZi0lwkfe6DqgSjeazosFKnRqIThYTcpHiEd1ACKWlUwZgcoHc51 LakJ9tJWBXnYsjZnYe6VhFkLLRPg/bDVPksJCGPpJq/A+7p4lUkRS5J+PdOHhtOkHmvn mfaRTdypW2FJxgUGSXK9m04DDykpPRKMqcZ6uXE9y5jh5AlcSZ/wsgBcpBHPqYxPBF30 qdPIMJW/lktpGKKMWZLXevJJoofnIcmDrutJOkBPz5Qa4hSXmp+07/gI58Gi4ko1nKNX Rd54fsMVvEatxdLYrG1gBrDwUpc3qyp4zWEQ10pJupODf11pFqAXhYhKxpjWagelh8xk WlMg== 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=SSozHCnZ47dgg+OhQOllMO1QAv6/Es62fq7RpKKqJSw=; b=LERwD0/Sk5/ae4UO5FhVlfNO9A9kw8HS3XsN3Sdc9KLcz3UnTbYpdZWLwJYOhhGK4T aXRluo0iTw+2VrXQg59Vl/9gri2Xzl0g7o9x1KzsK5K2VorG66qA5F8dGx6WOfp2EHmQ dsiRZHv+vYvM7rieH6reVysyEuJnllo+2k077om7+qjVAqCv7NIjewJfPRIPrfpo80Dx KFEvYNW3yhxsyAZiHN5TeuQt/RWgtdjfcCbO0MnDdSQWcPCiO3E7YQTF0yA1lixoJKJX 50qXLu5SlUyRGtVXWdzf657GOmmXOoAqUPjfdEqxNAj9v0ULHbRnzAgdqOzYE/Ezo7FL hqwQ== 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=SSozHCnZ47dgg+OhQOllMO1QAv6/Es62fq7RpKKqJSw=; b=drasr9cLtLKT21eo9ze8/S2/zdkjx+/Dwe6RQlHE6L/yYvyou90Q1x6mXHh+wD9b15 kgoWGX1dX2wps5IgVvX0j91YqmcDJBRCw7O6AKONLqiHI0/9+G0w8iD0LpWdM8F/Tmd9 7GCI3xBCsO9vAVN9LUqfSS6sDj/luDgEsSpBRoku3q586Vu9vqpEz+j3OQmsjIQ9ugQv OieBvRq1meo9+rW/fSp4Pj3OXRqVX/fi8i64MZ+3ayYMmd5pzduaHVhGf8ys32CP0kmF jEXqQFhN7NLolMZCba2ZTS0XvWn+EIdMnApN46Ceb8nAniBFCM70F8aPWW1DpJE//e1M jOjQ== X-Gm-Message-State: APt69E3Q2ZCx86HFXDn6c7RQj3rWp0cbVsPOe+kgaSIrRJaKuR4hUlbt gWu+LJ28Nn+Y3gmDzWy8tnd1fQ== X-Google-Smtp-Source: AAOMgpcEooA65ra+6bg/XwaxGPdzlei+lyXknIzr4k9682MYi9fV5RV9XG/mCo8CvgpmvIMNfI8J1A== X-Received: by 2002:a81:218b:: with SMTP id h133-v6mr6009306ywh.17.1531162595432; Mon, 09 Jul 2018 11:56:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:1481:: with SMTP id 123-v6ls2231984ywu.17.gmail; Mon, 09 Jul 2018 11:56:28 -0700 (PDT) X-Received: by 2002:a81:330a:: with SMTP id z10-v6mr2754832ywz.5.1531162588669; Mon, 09 Jul 2018 11:56:28 -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:39036 Archived-At: ------=_Part_110958_324298937.1531162588126 Content-Type: multipart/alternative; boundary="----=_Part_110959_1408536446.1531162588127" ------=_Part_110959_1408536446.1531162588127 Content-Type: text/plain; charset="UTF-8" On Monday, July 9, 2018 at 4:03:35 PM UTC+3, Richard Hodges wrote: > > > > On Mon, 9 Jul 2018 at 14:03, > wrote: > >> >> >> On Monday, July 9, 2018 at 1:38:12 PM UTC+3, Richard Hodges wrote: >>> >>> >>> >>> On Mon, 9 Jul 2018 at 12:01, wrote: >>> >>>> >>>> I got an idea this morning, here it is in code >>>> >>>> >>>> void func( width: int val ); >>>> void func( height: int val ); >>>> >>> >>> Starting to look a lot like objective-c's loathsome syntax. >>> >>> We can already do: >>> >>> void func(height val); >>> void func(width val); >>> >>> Where >>> >>> using height = tagged_value; >>> template struct tagged_value { .. implement in terms of >>> services expressed by the tag... }; >>> >>> Which is IMHO more expressive. >>> >>> An existing (very complete) model of this: >>> https://www.boost.org/doc/libs/1_67_0/doc/html/boost_units.html >>> >> >> This can't handle nearly enough cases and is much more intrusive to the >> function - val is now a different type, this leaks into the implementation >> as well >> > > > Different semantic meaning == different type is a *good thing* as it > allows relationships and operations to be checked at compile time. That > means fewer bugs. > > >> >> Also consider >> Rect(center: Point c, Size size); >> Rect(topLeft: Point tl, Size size); >> Rect(bottomLeft: Point bl, Size size); >> >> Semantically some BottomLeftPointType is just wrong >> > > It's only wrong if the behaviour of a bottom-left point is different to > the behaviour of a top-left point. If it's not, then why bother tagging? > The user must say what point he is supplying so the ctor can fill the rest by using size. Rect({0, 0}, {10, 12}) // top:0 left:0 bottom: 12 right:10 Rect(center: {0, 0}, {10, 12}) // top:-5 left:-6 bottom: 5 right: 6 The points are the same, making them different type is wrong semantically as you probably agree. > >> >> >> In general very often we want *both* the old types and the old function >> name, but to have a different implementation (to do something different). >> >> This is why tags are so great and this suggestion is just an extension of >> that, the same way structured binding are syntax sugar for the returned >> struct. >> >> >> More real word examples (slightly modified) >> >> QImage(serializedData: const uchar *data, int size, const char *format = >> {}); >> > > QImage(ByteBuffer const&, FormatString const&); // semantically > meaningful, 1 fewer arguments, fewer errors > This still does not work - ByteBuffer can be raw pixel data or can be compressed (Jpeg) and the format can be omitted. We must introduce SerializedByteBuffer. Note that I agree with you in principal, but new type can be redundant (if used just in one place) or it might not scale - there might be dozens overloads > > >> QByteArray(base64: const QByteArray& val); >> QByteArray(percentEncoded: const QByteArray& val, char percent = '%') >> >> QByteArray(parseNumber: int val); >> QByteArray(parseNumber: double val); >> >> Note the last two in particular - special type will be *completely* >> redundant - parseDoubleNumber{5} or something like that. >> > > template struct parse_number { ... }; > QByteArray(parse_number(5)); //c++17 template type deduction yields > parse_number > QByteArray(parse_number(5.0)); //c++17 template type deduction yields > parse_number > This is confusing as it looks like we create a byte array by a function (or functor) and pass it to the a ctor. It also leaks detail into the implementation - we must code in terms of some odd parse_number argument. This is just a workaround, not something semantically better (as arguably the Buffer example) In general named params are The Right Solution if the types must semantically stay the same (incl. in the implementation) - Points, numbers, but often strings, images. - First, middle, last name should not be a different type (well depends on the language, but you get the idea). - Window title icon and window tray icon should not be a different type. - Header text should not be different type then Footer text - Tooltip and status text are the same type of string - 16x16, 24x24, 32x32 etc in a icon class are the same type - an image Honestly, the list is long, we just don't notice it as we learned to get around of it in one form or another, modeling our interfaces around the issues or simply dropping useful interfaces as they are hard or cumbersome to express . > > > There was a great CppCon talk on this. It's worth seeking out. > >> >> >> >> -- >> 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-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> To view this discussion on the web visit >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/da3e4418-e043-4ad4-bab4-513ddd633abe%40isocpp.org >> >> . >> > -- 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/41949fb9-c3b6-4d16-a760-2d9064bce683%40isocpp.org. ------=_Part_110959_1408536446.1531162588127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, July 9, 2018 at 4:03:35 PM UTC+3, Richa= rd Hodges wrote:


On Mon, 9 Jul 2018 a= t 14:03, <mihailn...@gmail.com> wrote:


On Monday, July 9, 2018 at 1:38:12 PM UTC= +3, Richard Hodges wrote:


On Mon, 9 Jul = 2018 at 12:01, <mihailn...@gmail.com> wrote:<= br>

I got an idea this morning, here it is in code


void func(=C2=A0 width: int val );void func(=C2=A0 height: int val );
<= br>
Starting to look a lot like objective-c's=C2=A0loathsome=C2=A0syntax.

We can alr= eady do:

<= /div>
= void func(height= val);
void func(width val);

Where=

using height = =3D tagged_value<struct height_tag, int>;
template<typename Tag> struct tagged_value { .. implement in terms of services expressed by the tag= .... };

=C2=A0Which is IMHO more expr= essive.

An existing (very complete) model of this:= =C2=A0https://www.boost.o= rg/doc/libs/1_67_0/doc/html/boost_units.html

This can't handle nearly enough cases= and is much more intrusive to the function - val is now a different type, = this leaks into the implementation as well
=C2=A0
<= div>Different semantic meaning =3D=3D different type is a *good thing* as i= t allows relationships and operations to be checked at compile time. That m= eans fewer bugs.=C2=A0
=C2=A0

Also consider=C2=A0
Rect(c= enter: Point c, Size size);
Rect(topLeft: Point tl, Si= ze size);
Rect(bottomLeft: Point bl, Size size);

Semantically some BottomLeftPointType is just wrong=

It's only wrong if the beh= aviour of a bottom-left point is different to the behaviour of a top-left p= oint. If it's not, then why bother tagging?

The user must say what point he is supplying so the = ctor can fill the rest by using size.=C2=A0

Rect({0, 0}, {10, 12}) // top:0 left:0 botto= m: 12 right:10

Rect(center: {0, 0}, {10, 12}) // top:-5 left:-6 bottom: 5 r= ight: 6

=C2=A0The points a= re the same, making them different type is wrong semantically as you probab= ly agree.

=C2=A0


In general very often we want both the old types an= d the old function name, but to have a different implementation (to do some= thing different).=C2=A0

This i= s why tags are so great and this suggestion is just an extension of that, t= he same way structured binding are syntax sugar for the returned struct.


More re= al word examples (slightly modified)

QImage(serializedData: const uchar *data, int size, c= onst char *format =3D {});

QImage(ByteBuffer const&, FormatS= tring const&);=C2=A0 =C2=A0 // semantically meaningful, 1 fewer argumen= ts, fewer errors

<= br>
This still does not work - ByteBuffer can be raw pixel data o= r can be compressed (Jpeg) and the format can be omitted. We must introduce= SerializedByteBuffer.=C2=A0

Note that I agree wit= h you in principal, but new type can be redundant (if used just in one plac= e) or it might not scale - there might be dozens overloads
=C2=A0=


QByteArray(base64: const = QByteArray& val);
QByteArray(percentEncoded: const QByteArray& v= al, char percent =3D '%')

QByteArray(parseNumber: int val);= =C2=A0
QByteArray(parseNumber:= double val);

=
Note the last two in particular - special type will be=C2=A0 comple= tely redundant - parseDoubleNumber{5} or something like that.

temp= late<class Numeric> struct parse_number { ... };
QByteArray(parse_number(5));=C2=A0 =C2=A0 //c++17 template type dedu= ction yields parse_number<int>
QByteArray(parse= _number(5.0));=C2=A0=C2=A0//= c++17 template type deduction yields parse_number<double>

This is confusin= g as it looks like we create a byte array by a function (or functor) and pa= ss it to the a ctor.
It also leaks detail into the implementation= - we must code in terms of some odd = parse_number argument.=C2=A0<= /div>

This is just a workaround, not something seman= tically better (as arguably the Buffer example)

In general named params are The Right Solution i= f the types must semantically stay the same (incl. in the implementation) -= Points, numbers, but often strings, images.

  • First, middle, last name should not be a diff= erent type (well depends on the language, but you get the idea).=C2=A0
  • Window title icon and window tra= y icon should not be a different type.
  • Header text should not be different type then Footer text=
  • Tooltip and status text are the sa= me type of string
  • 16x16, 24x= 24, 32x32 etc in a icon class are the same type - an image
    • <= /ul>
    Honestly, the list is long, we jus= t don't notice it as we learned to get around of it in one form or anot= her,
    modeling our interfaces around the issues or simply dropping= useful interfaces as they are hard or cumbersome to express .
    =
    =C2=A0


    =C2=A0There was a gr= eat CppCon talk on this. It's worth seeking out.



    =

    --
    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-proposal...@isocpp.org.
    To post to this group, send email to std-pr...@isocpp.org.
    To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/da3e4418-e043-4ad4-bab4-= 513ddd633abe%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/41949fb9-c3b6-4d16-a760-2d9064bce683= %40isocpp.org.
------=_Part_110959_1408536446.1531162588127-- ------=_Part_110958_324298937.1531162588126-- .