220 29335 article Path: news.gmane.org!.POSTED!not-for-mail From: Jared Grubb Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: std::byte thoughts Date: Tue, 1 Nov 2016 23:40:42 -0700 (PDT) Lines: 177 Approved: news@gmane.org Message-ID: References: <7da80620-e4bd-40eb-a4ec-4f3c2dcb2c98@isocpp.org> <1549171.TC16PSHVVd@tjmaciei-mobl1> <2350841.Z7lUCKSumT@tjmaciei-mobl1> <3e64b220-79ae-4108-ba1c-9785494fc434@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_895_1598619982.1478068842320" X-Trace: blaine.gmane.org 1478068855 10694 195.159.176.226 (2 Nov 2016 06:40:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Nov 2016 06:40:55 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDVKDF4E7IDRB24U43AAKGQEWM7SHXY@isocpp.org Wed Nov 02 07:40:51 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f198.google.com ([209.85.220.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1pE1-00018h-7m for gclcip-std-proposals@m.gmane.org; Wed, 02 Nov 2016 07:40:41 +0100 Original-Received: by mail-qk0-f198.google.com with SMTP id h201sf6205185qke.7 for ; Tue, 01 Nov 2016 23:40:44 -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=hwLeLJit8etLwbwMO5lLib041rINDnV0yiNhxZTxYpE=; b=1P/atLnE7qt4b5KDsZe4QCmTQTFFP/OVm4J7NOOM8GQjQVlKBiHKiYQrNg4ZKHj1Yo HJFK7uTuwawSnKZnwu4DDTEAOP7QsRfhRCejZflCFV5B1wtkURMEY06bh/jo6mKiN7CP YfZqPAdMhXbbL99X9ZV+O161snUf1MHc9GklwyxlIH906BCeMcu00m+FpUPjHhQkEmNM dP6e0wxtKsYl3TkP+PdVTXnBJejFRrR4K2eOaGvGzNtVBVdeZ085aTqTtDAft63tnJdP FpqGtp7o0XzLkjM37YOOCHZH1+YJbBpvfXWLvrjA7JckBgUYU82Mdz80/gHDkdG6JQD1 +8aQ== 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=hwLeLJit8etLwbwMO5lLib041rINDnV0yiNhxZTxYpE=; b=zeoIgFPEGzhWdlRBvw10x6TwmPIe1+hlP+UvqY1r8bbNopUua47cf1Q0YOLPWp893R AE45xSY4kgAo8Lm8lLu2cNVGfgJx4+i0WZJY5yNgXEf//qo72eVHSxc3UzDfwi5eYfFm m6vZAkxznTr7wnZ5gE8FdzH7t+xj4VQLEcuh3nFyzuPC8Bz3W9Q3KGgLz6Qa0t5MiY5M 4RSuEVNPttiF+q9dHx8arvzM3xqEuUmx3/eYmBTczhGsIxrQQPy2Wu0l+T93gHJc16vU TJ1q5Sx+3qwOf15px/26zTEDK0pLDW9MPPxSp+JGaAv72uUnibpPdV1vt0aEYWxstvtj 4SXA== 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=hwLeLJit8etLwbwMO5lLib041rINDnV0yiNhxZTxYpE=; b=WKJEbxEnbbV07T4GB1qoM4WmpbnHvlImwhfJP7ZbBdsAOvMdIrB9jIvvEI+eZU5WaT VYBmxIyaC65Yu0vljA0HD2Um6GxuprrjbfdGseV5RSQfSoVSO00/t3urifuMiZhTi/gM QQhZPsKVT/mueYkOv56sZk/4oXAUME58usVmlnJJ1XTsY0mgHNWEvmh5Yb7UBUZXfHky Y9dGxUmRoi+FMQF1bMDD0TZz15C/BH7WKVzgk0khbLXjxjvU1Duil6+Dh4DldoiLYdDN /mbeC7ZQei8Sn+F61L2xHu+aXeBFfPB3Yk/oTGhHqjLQNzMbInha+zNsKR7GHvSWq0q7 yCzw== X-Gm-Message-State: ABUngvcGPsZ2HDNhBeJnJLH0Xe7tZtyHwvgiFCHKz/EQqdgBDjWooaK0BLzQf7tFbVOleA== X-Received: by 10.200.50.244 with SMTP id a49mr492725qtb.81.1478068843817; Tue, 01 Nov 2016 23:40:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.34.72 with SMTP id o66ls17559983ota.17.gmail; Tue, 01 Nov 2016 23:40:43 -0700 (PDT) X-Received: by 10.157.8.134 with SMTP id 6mr37857otf.17.1478068842992; Tue, 01 Nov 2016 23:40:42 -0700 (PDT) In-Reply-To: <3e64b220-79ae-4108-ba1c-9785494fc434@isocpp.org> X-Original-Sender: jared.grubb@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:29335 Archived-At: ------=_Part_895_1598619982.1478068842320 Content-Type: multipart/alternative; boundary="----=_Part_896_2019922534.1478068842320" ------=_Part_896_2019922534.1478068842320 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, November 1, 2016 at 10:16:32 PM UTC-7, Nicol Bolas wrote: > > On Wednesday, November 2, 2016 at 12:55:46 AM UTC-4, Thiago Macieira wrot= e: >> >> Em ter=C3=A7a-feira, 1 de novembro de 2016, =C3=A0s 20:10:28 PDT, Nicol = Bolas=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= =20 >> it 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 byte= s=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 b= e=20 > inter-convertible, numerically speaking, but they don't mean the same thi= ng. > > 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 a= nd=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. > 100% agree. I know I've had a few cases where I was annoyed by the lack of= =20 an 8-bit number type. Although this proposal does *not* fix the=20 inconsistency in the following example, it at least provides an 8-bit=20 option. int main() { std::cout << (uint32_t)65 << '\n'; std::cout << (uint16_t)65 << '\n'; std::cout << (uint8_t)65 << '\n'; // Surprise! } =20 --=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/b2769718-6557-4107-9038-d1e7ade05ad5%40isocpp.or= g. ------=_Part_896_2019922534.1478068842320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, November 1, 2016 at 10:16:32 PM UTC-7,= Nicol Bolas wrote:
On Wednesday, November 2, 2016 at 12:55:46 AM UTC-4, Thiago Macieira = wrote:
Em ter=C3=A7a-feira, 1 de nov= embro 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.

100% agree= .. I know I've had a few cases where I was annoyed by the lack of an 8-b= it number type. Although this proposal does not fix the inconsistenc= y in the following example, it at least provides an 8-bit option.

in= t main()
{
=C2=A0=C2=A0=C2=A0 std::cout << (uint32_t)65 <<= ; '\n';
=C2=A0=C2=A0=C2=A0 std::cout << (uint16_t)65 <&= lt; '\n';
=C2=A0=C2=A0=C2=A0 std::cout << (uint8_t)65 <= < '\n'; // Surprise!
}
=C2=A0

--
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/b2769718-6557-4107-9038-d1e7ade05ad5= %40isocpp.org.
------=_Part_896_2019922534.1478068842320-- ------=_Part_895_1598619982.1478068842320-- .