220 29337 <97ebfc84-c5a3-eaf5-efcb-c1bdf9b507a5@gmail.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Andrey Semashev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: std::byte thoughts Date: Wed, 2 Nov 2016 12:02:04 +0300 Lines: 85 Approved: news@gmane.org Message-ID: <97ebfc84-c5a3-eaf5-efcb-c1bdf9b507a5@gmail.com> 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: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1478077340 23392 195.159.176.226 (2 Nov 2016 09:02:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Nov 2016 09:02:20 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCXY5TXHWYJRBD6X43AAKGQEU7AQFLY@isocpp.org Wed Nov 02 10:02:13 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f72.google.com ([209.85.215.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1rQr-00049V-EH for gclcip-std-proposals@m.gmane.org; Wed, 02 Nov 2016 10:02:05 +0100 Original-Received: by mail-lf0-f72.google.com with SMTP id i187sf1909040lfe.4 for ; Wed, 02 Nov 2016 02:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding: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=5cODicY9Zp0ZBqUfSuD0i4YMrV3YYrD757W9kxrigoo=; b=l76J2Zi+HhRqZ8zE507pmZmp0HD9aybnO/HfpznjwIfh/Wg75Vivkbpqykv5heK2s/ zDYPJJsSkhwlCE1iRAFDCOQjmEgiTBwK9pJHrCj7qWBDNeBhPCwPCeolsp3X+sHmLbAB ytIVxKIM59V0mXIblxLWMll0JRbMuswEs8/KD8877ZSPcahPiIUeIl7AMswGIZhcaCAs TJbUWIVmjr1wgidq17MUR8ikXWdJxKybCYiK+1I4GQWyX9HwFHkEams8cAyUylANkUl5 4mcBS06j9sc3LBJ/J2y4Cn0C3bZ/QgDhBY3NuhAGzwNNsJZu2StI9CKkhjYsOQr7MKsh X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :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=5cODicY9Zp0ZBqUfSuD0i4YMrV3YYrD757W9kxrigoo=; b=cn7LQSqGS0k5ECHufTePcn4LNaw4mey4yfkCDCt/ce/SpDUGuzca2tP17yA+/vz+cJ OiAMJkRFuZ175S0diftnjBtSTdXv/hKb28JU/iOvy6EJg3tcpDvwlgA769RWqYy4/y/V IP9rdYXRINQ7p1VJhPfk64vs4zFaiTqNMjEwLbNudkCr+Oj8Du2f2jfgGwA9VNdO9oXo vu9ya/LLEa++hf7x+sz4f+al0NSFsM3h/K8wWfGV4jxr5vmUen5vB037An5cLZ35QNZB HjY0lXdq248Jw34wiLNM6dZjZNZhlAS65pAgn6YEfWA25R7+G18CgCNf8WpCrxHUkGLD X-Gm-Message-State: ABUngvefePz1bJicJTRX+DZno/2wZuUJE1dGH9E5o49OfP2Q73UYiVlFG/+r/8Ji5l/6Ag== X-Received: by 10.25.32.195 with SMTP id g186mr132632lfg.23.1478077328456; Wed, 02 Nov 2016 02:02:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.43.18 with SMTP id r18ls418742lfr.34.gmail; Wed, 02 Nov 2016 02:02:07 -0700 (PDT) X-Received: by 10.25.219.151 with SMTP id t23mr1295520lfi.105.1478077327142; Wed, 02 Nov 2016 02:02:07 -0700 (PDT) Original-Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com. [2a00:1450:4010:c07::236]) by mx.google.com with ESMTPS id q15si623008lfi.360.2016.11.02.02.02.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 02:02:06 -0700 (PDT) Received-SPF: pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::236 as permitted sender) client-ip=2a00:1450:4010:c07::236; Original-Received: by mail-lf0-x236.google.com with SMTP id t196so6871365lff.3 for ; Wed, 02 Nov 2016 02:02:06 -0700 (PDT) X-Received: by 10.25.72.74 with SMTP id v71mr1308750lfa.130.1478077326188; Wed, 02 Nov 2016 02:02:06 -0700 (PDT) Original-Received: from [192.168.1.2] (broadband-90-154-68-136.nationalcablenetworks.ru. [90.154.68.136]) by smtp.googlemail.com with ESMTPSA id l135sm218727lfg.30.2016.11.02.02.02.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 02:02:05 -0700 (PDT) In-Reply-To: <3e64b220-79ae-4108-ba1c-9785494fc434@isocpp.org> X-Original-Sender: andrey.semashev@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::236 as permitted sender) smtp.mailfrom=andrey.semashev@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:29337 Archived-At: On 11/02/16 08:16, 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, Nic= ol Bolas > escreveu: > > Actually, no. `std::byte` as proposed by P0298 is explicitly *not* = a > > typedef. It is a scoped enumeration whose underlying type is > `unsigned > > char`, but it is not a typedef. > > > > 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 > defintion, a > byte. Why should we have (more) types that mean exactly the same > thing, and > this time in all platforms, by definition? > > > Because "unsigned char" /also/ means "unsigned character". With just > `unsigned char`, there is no way to distinguish between manipulating > bytes and manipulating unsigned characters. And what is "unsigned character", exactly? The standard defines a=20 character set, but leaves character encoding implementation-defined,=20 except that it says that code units are representable by char. Assuming=20 that code units are always positive (which I don't think is mandated=20 anywhere, but let's keep things sane), you could also store code units=20 as unsigned chars. But neither char nor unsigned char represents a=20 character, unless a code point is equivalent to a code unit. I think when you say "unsigned character" you should actually be saying=20 "code units", and at this point it's not that much different from=20 "bytes". I think, unsigned char should be considered as byte in every=20 respect; if such a type is added to C++, it should either be a regular=20 typedef (std::byte_t) or an intrinsic integral type that is equivalent=20 to unsigned char. > 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's no reason why `byte` > should not be an integral type. Agreed. > Think about it. The C++ standard allows a break in strict aliasing rules > for `unsigned char` and `char`. Why? Not because the standard thinks > it's reasonable 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 from > `uint_least16_t`. Because there is a fundamental semantic difference > between an array of unsigned integers that are at least 16-bits in size > 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 code units, for > that matter. Thing is, unsigned char is already allowed to alias, and if we add the=20 intrinsic byte type that is also allowed to alias, we don't make that=20 distinction you talk about. And if we prohibit unsigned char to alias=20 other types, we will render lots of existing code invalid. We could add=20 an intrinsic char8_t instead and say it will only represent narrow=20 character code units and not alias other types. This way unsigned char=20 is left as the "byte" type and we have the other type for string processing= .. --=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/97ebfc84-c5a3-eaf5-efcb-c1bdf9b507a5%40gmail.com= .. .