220 29334 <3e64b220-79ae-4108-ba1c-9785494fc434@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: std::byte thoughts Date: Tue, 1 Nov 2016 22:16:32 -0700 (PDT) Lines: 143 Approved: news@gmane.org Message-ID: <3e64b220-79ae-4108-ba1c-9785494fc434@isocpp.org> References: <7da80620-e4bd-40eb-a4ec-4f3c2dcb2c98@isocpp.org> <1549171.TC16PSHVVd@tjmaciei-mobl1> <2350841.Z7lUCKSumT@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3205_1180560473.1478063792641" X-Trace: blaine.gmane.org 1478063812 8855 195.159.176.226 (2 Nov 2016 05:16:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Nov 2016 05:16:52 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBMPN4XAAKGQEE23FFKA@isocpp.org Wed Nov 02 06:16:48 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1nuZ-0007uk-Da for gclcip-std-proposals@m.gmane.org; Wed, 02 Nov 2016 06:16:31 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id 128sf12117462oih.1 for ; Tue, 01 Nov 2016 22:16:34 -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=IB1A3HGXqf8SE6PJ+FrM9a63BoeGtwWzvUywn+I/Ba0=; b=CrrPnrq4ouMBtQJGDiUAA76XyEjRSoZbMXljOO9Wyx+jk80UI2sTS9h0c9LfYJ1WgP fUWztfjcyQY0g2HhKWzHazwNf/w9RNlJhAWkkAiIAQkAMXboCKcDM3a15wj+L4PXAHdN gekV8QW1JmHLsOhy3HRvQX4Fy8xXsrPA9DxwIpFCJ984TzVxIDDsDc8l3E15TaIRFtPI mCwDRwt4wwQTcXA7L0tSKmctYLUGfuK2zs//rtaw115bInURxqrgkzNN4ZqWM8sq2oHe 6H3oTkkl7uEgC0XShxuMste6fFg9Mg5T+UF8yUYdIQYcHDC8HWgQTiiDCSdiOq/Ux9QT sNhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=IB1A3HGXqf8SE6PJ+FrM9a63BoeGtwWzvUywn+I/Ba0=; b=dVuYMX3MtqpZGKvuNvzywFbp/kDeKntzuAVEdSJpXRAtHlHX2Ka/9xmjxSAkY9dwmW l+a7e98PdpfXEmJcNhqbVabdb6Mi3k/8q12iSsU1jPXE89ymfHJUHMu2IL8OAU7uLuIk vG1cQUslHxPwRxLVZLLzmm2Nwbj7KZ+XnKD3qIkxrDO6pbxF4UAWrLqxedZCU2fxz5j7 mIzTxVu1siG9sDnzSd0G35SmnBqGqZHHCkf11vkyFK8R9wsk7tCYKf3kN5iHx7vFvXUB MeznZQNzaXX/vMwHMBuED6OCGCeueovjASx3OwjJ3GOimoDFijjRDe9okDPRJ0uiP/eH P7bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=IB1A3HGXqf8SE6PJ+FrM9a63BoeGtwWzvUywn+I/Ba0=; b=XVioUCXtc5592jHdaHGq6h17CLd8xnLkli+4XnXedMnqC9a2Ag3cbjNBj6g9RehYPI 0LA0hBl+gyiTX4gyOxmAGPJUa8jL4A6nuVd9qM75DrZkXMroExvhBCQm0YnB+Hq6EIBy UUSkTWa02bbrd130Mu3qZJ2364qT+0BXBTBBsb80AVfutUESL2tRBijFXRAxOvVkAseW IYkxstfrdkuBUh+NVHCcsDXCoyCHSYmVzFnDfojG1m2xRN+H1szDnTC2g0dn+N5S6/zI 1RF403GqgIoieseLRdIQuaoZWE5nX59mdfG7Fpj1o9Vcf8T77yJSJXnuUWvTVMmmN+Qw Wc4A== X-Gm-Message-State: ABUngveAzEh80VEIiA1V17B08WYsPtbnRd9YeW1MxZLu4/M+Z7bRCpw0/UnObdkBSrIv0w== X-Received: by 10.157.53.90 with SMTP id l26mr439347ote.72.1478063793975; Tue, 01 Nov 2016 22:16:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.23.235 with SMTP id j98ls1001489otj.47.gmail; Tue, 01 Nov 2016 22:16:33 -0700 (PDT) X-Received: by 10.157.39.131 with SMTP id c3mr29690otb.15.1478063793219; Tue, 01 Nov 2016 22:16:33 -0700 (PDT) In-Reply-To: <2350841.Z7lUCKSumT@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:29334 Archived-At: ------=_Part_3205_1180560473.1478063792641 Content-Type: multipart/alternative; boundary="----=_Part_3206_760360212.1478063792641" ------=_Part_3206_760360212.1478063792641 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, November 2, 2016 at 12:55:46 AM UTC-4, Thiago Macieira wrote: > > Em ter=C3=A7a-feira, 1 de novembro de 2016, =C3=A0s 20:10:28 PDT, Nicol B= olas=20 > escreveu:=20 > > Actually, no. `std::byte` as proposed by P0298 is explicitly *not* a=20 > > typedef. It is a scoped enumeration whose underlying type is `unsigned= =20 > > char`, but it is not a typedef.=20 > >=20 > > Granted, I can't agree with that design decision. I would much rather i= t=20 > be=20 > > a genuine type, rather than using C++ enum chicanery to get strong=20 > aliases.=20 > > That would also not be a good idea because, unsigned char is, by=20 > defintion, a=20 > byte. Why should we have (more) types that mean exactly the same thing,= =20 > and=20 > this time in all platforms, by definition?=20 > Because "unsigned char" *also* means "unsigned character". With just=20 `unsigned char`, there is no way to distinguish between manipulating bytes= =20 and manipulating unsigned characters. That's what `byte` is for, as a type: a way to semantically differentiate= =20 between operations on bytes and operations on characters. The types can be= =20 inter-convertible, numerically speaking, but they don't mean the same thing= .. My problem with using C++ enum chicanery is that, if you use the type=20 traits mechanisms to ask what `std::byte` is, it will say that it's an=20 enum, not that it's an integral type. There's no reason why `byte` should= =20 not be an integral type. Think about it. The C++ standard allows a break in strict aliasing rules=20 for `unsigned char` and `char`. Why? Not because the standard thinks it's= =20 reasonable for people to alias UTF-8 strings. But because that's the only= =20 way to pass/manipulate a byte array. And byte arrays need to be able to=20 alias. It's the same reason why we have `char16_t` as a distinct type from=20 `uint_least16_t`. Because there is a fundamental semantic difference=20 between an array of unsigned integers that are at least 16-bits in size and= =20 an array of UTF-16 code units. One of this is a string; the other is not. It's time we had such a distinction for bytes. And UTF-8 code units, for=20 that matter. --=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/3e64b220-79ae-4108-ba1c-9785494fc434%40isocpp.or= g. ------=_Part_3206_760360212.1478063792641 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, November 2, 2016 at 12:55:46 AM UTC-4, Thiag= o Macieira wrote:
Em ter=C3=A7a= -feira, 1 de novembro de 2016, =C3=A0s 20:10:28 PDT, Nicol Bolas escreveu:
> Actually, no. `std::byte` as proposed by P0298 is explicitly *not*= a
> typedef. It is a scoped enumeration whose underlying type is `unsi= gned
> char`, but it is not a typedef.
>=20
> Granted, I can't agree with that design decision. I would much= rather it be
> a genuine type, rather than using C++ enum chicanery to get strong= aliases.

That would also not be a good idea because, unsigned char is, by defint= ion, a=20
byte. Why should we have (more) types that mean exactly the same thing,= and=20
this time in all platforms, by definition?

Because "unsigned char" also mea= ns "unsigned character". With just `unsigned char`, there is no w= ay to distinguish between manipulating bytes and manipulating unsigned char= acters.

That's what `byte` is for, as a type: a way to semantica= lly differentiate between operations on bytes and operations on characters.= The types can be inter-convertible, numerically speaking, but they don'= ;t mean the same thing.

My problem with using C++ enum chicanery is = that, if you use the type traits mechanisms to ask what `std::byte` is, it = will say that it's an enum, not that it's an integral type. There&#= 39;s no reason why `byte` should not be an integral type.

Think abou= t it. The C++ standard allows a break in strict aliasing rules for `unsigne= d char` and `char`. Why? Not because the standard thinks it's reasonabl= e for people to alias UTF-8 strings. But because that's the only way to= pass/manipulate a byte array. And byte arrays need to be able to alias.
It's the same reason why we have `char16_t` as a distinct type fro= m=20 `uint_least16_t`. Because there is a fundamental semantic difference=20 between an array of unsigned integers that are at least 16-bits in size=20 and an array of UTF-16 code units. One of this is a string; the other is not.

It's time we had such a distinction for bytes. And UTF-8 c= ode units, for that matter.

--
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/3e64b220-79ae-4108-ba1c-9785494fc434= %40isocpp.org.
------=_Part_3206_760360212.1478063792641-- ------=_Part_3205_1180560473.1478063792641-- .