220 29272 <7da80620-e4bd-40eb-a4ec-4f3c2dcb2c98@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: pecholt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: std::byte thoughts Date: Mon, 31 Oct 2016 05:28:20 -0700 (PDT) Lines: 107 Approved: news@gmane.org Message-ID: <7da80620-e4bd-40eb-a4ec-4f3c2dcb2c98@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1716_1413286481.1477916900581" X-Trace: blaine.gmane.org 1477916938 30169 195.159.176.226 (31 Oct 2016 12:28:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 31 Oct 2016 12:28:58 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD6KHDH5WIDBBZPR3TAAKGQEWZ6OVDA@isocpp.org Mon Oct 31 13:28:54 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1BhL-0003Th-Ae for gclcip-std-proposals@m.gmane.org; Mon, 31 Oct 2016 13:28:19 +0100 Original-Received: by mail-pa0-f72.google.com with SMTP id r13sf94356950pag.1 for ; Mon, 31 Oct 2016 05:28:22 -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: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=gTmciuYiEA2S3HqADETXtVusSf1Pv32M859HvdN3Hjk=; b=uzHNwBkgeN4Uns3qAaCiATEHsDmPKxI+11wvi1NIXa2diPw5DazBENBjnxJclWKQvO YyMivu6AeSCTr20cumH8ezT1CR64W8/OI7Vi6qjjZdarQICfoUphKD4d6PSsheUz0Av1 pVOufy+g/dDzOQwv4b+4n8jdFaFcqM73945plONyp5QhcbZzfmsLotxa24UzEi83V4rE ZVlwVFb70blnv/uuP1UUCGT4TYK+Iz8gVz3MuEDE95UCe3o7a9jyzlV/7nbwwkDPPKL2 2Ot54iYopZ7L7y/Z6/CMox4/RnmLINVYmGBLvA8pkms0+9sAB9Vnhr9BYbibG+eAX+wR Rc+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id: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=gTmciuYiEA2S3HqADETXtVusSf1Pv32M859HvdN3Hjk=; b=kfRwr4DZKD6hAd4Jwfj8hSI1dfN8fxTCYGZncaDgvdWru/koQe/OCpOg8RmHylRKcf SMzl3kwOm6Tqa1O3l7QWgGRuxivh9YUjqPIvDhjRidw9lQ0F5lwe5wTRkdzUMRka58Dm C0gwJqEdhNDWa+lDkH9p/iXfg1mUj/WMFow+M/G1zBEPsqQFtsaONhjMGt0X5DLL2RC8 rLCD9mtwipbJ0cl2od9nTIXWm9GHxJZi9mGtQl17XKuoKb1pABtoIb1guzZPiOwXmv7g sCHN67wVSXYQXLeql3XHVjQT3opevcfmt09f0riaRNxwDa+E/m50nNB0jlpB6IrOAwgR QotQ== 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: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=gTmciuYiEA2S3HqADETXtVusSf1Pv32M859HvdN3Hjk=; b=ka67eyEpHMuzLcDa0FK4rkkj9S01cfW/pgcTRqx5cNVzGOxNSFA1bEqKhovDciBrGU TaS9dyIQGeqTbWC6yK1A0hMKseGKmm/PGclUavqPnGvFdkFA6bysOWRrEO5gl3xZT8B6 Heljj036BiW5lHaOaKNLLKBnUmWLGhlaHUNRevgvtrwfU6RlGqzVl0Zgk6p5+f8Afa1f X83WEGbehnwtkYAUqG3bZsom2Uunjf8e1Wycn9Aaw8fflA4CEaL17lehKLbiu7pw9qZH Zo5RDNAgq06TjarPZapiPKGUCm/OtaFhydHR3F1mc4q3Hd+eQrMzqAjq0bj0XduSEyLH 0DaQ== X-Gm-Message-State: ABUngveWqkbPf4N6JTS1T7toDaWoufvVv+sA2/cOexaso1Ehs+oZtnBqK24WtyuoJ3HO+A== X-Received: by 10.98.80.8 with SMTP id e8mr9750202pfb.31.1477916901666; Mon, 31 Oct 2016 05:28:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.41.209 with SMTP id g17ls52699otd.46.gmail; Mon, 31 Oct 2016 05:28:21 -0700 (PDT) X-Received: by 10.157.14.231 with SMTP id 94mr2578990otj.9.1477916900999; Mon, 31 Oct 2016 05:28:20 -0700 (PDT) X-Original-Sender: pecholt@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:29272 Archived-At: ------=_Part_1716_1413286481.1477916900581 Content-Type: multipart/alternative; boundary="----=_Part_1717_1049496307.1477916900581" ------=_Part_1717_1049496307.1477916900581 Content-Type: text/plain; charset=UTF-8 I noticed "a byte type definition" proposal (P0298R1) in last wg21 mailings and I want to share some concerns. While I agree fundamental byte type is indeed missing in C++ and should be added I don't think the presented way is the right one. The proposal suggests to add it as a library type in namespace std. It argues C++17 is expressive enough for a simple library definition, as opposed to a keyword. I am not saying it's not possible but the question is if the new type is added this way will it fit with other fundamental types defined as keywords? Will it bring confusion to the users? And this is a weak point of this proposal imho. The fundamental type set can be already seen as confusing. First we have shortcuts like *short int* becomes a *short*, *signed int* becomes *int *etc. This is obviously shared with C and cannot be changed. We are all used to live with that. But then there is a *char* as a distinct type not a shortcut for *signed char*. OK confusion number one but it happened long time ago so nothing to do here too. Then the user has to learn some newly added types contain _t suffix like *wchar_t*, *char16_t* and *char32_t*. Most inexperienced programmers tend to think _t means a typedefed type because that is a convention used by some libraries. *wchar_t* was really implemented as a typedef in earlier MS compilers. But that's no longer true. All these types are distinct opaque types so typedef cannot be used for that. I assume _t was used as an uglifier which helps preserving source code compatibility. So confusion number two. And now we want to add *std::byte*. I guess using namespace std everywhere is not a good practice and using it in headers is widely considered wrong. So users will have to learn another rule - new generation types have to be prefixed with namespace qualifier. I cannot imagine any other way how to bring the confusion to a higher level than this. We are still talking about fundamental type set not anything complicated. Simplicity and clarity matters. So why so many rules, exceptions and experiments? Why don't we use byte_t keyword so it will at least fit with 2nd generation types? If that is not possible I consider the new proposal so confusing to the users that it shouldn't be accepted. We live without it since the beginning anyway. What do the others here think? -- 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/7da80620-e4bd-40eb-a4ec-4f3c2dcb2c98%40isocpp.org. ------=_Part_1717_1049496307.1477916900581 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I noticed "a byte type definition" proposal (P02= 98R1) in last wg21 mailings and I want to share some concerns. While I agre= e fundamental byte type is indeed missing in C++ and should be added I don&= #39;t think the presented way is the right one. The proposal suggests to ad= d it as a library type in namespace std. It argues C++17 is expressive enou= gh for a simple library definition, as opposed to a keyword. I am not sayin= g it's not possible but the question is if the new type is added this w= ay will it fit with other fundamental types defined as keywords? Will it br= ing confusion to the users? And this is a weak point of this proposal imho.=

The fundamental type set can be already seen as confusing. First we= have shortcuts like short int becomes a short, signed int= becomes int etc. This is obviously shared with C and cannot be = changed. We are all used to live with that. But then there is a char= as a distinct type not a shortcut for signed char. OK confusion num= ber one but it happened long time ago so nothing to do here too. Then the u= ser has to learn some newly added types contain _t suffix like wchar_t, char16_t and char32_t. Most inexperienced programmers ten= d to think _t means a typedefed type because that is a convention used by s= ome libraries. wchar_t was really implemented as a typedef in earlie= r MS compilers. But that's no longer true. All these types are distinct= opaque types so typedef cannot be used for that. I assume _t was used as a= n uglifier which helps preserving source code compatibility. So confusion n= umber two. And now we want to add std::byte. I guess using namespace= std everywhere is not a good practice and using it in headers is widely co= nsidered wrong. So users will have to learn another rule - new generation t= ypes have to be prefixed with namespace qualifier. I cannot imagine any oth= er way how to bring the confusion to a higher level than this.

We a= re still talking about fundamental type set not anything complicated. Simpl= icity and clarity matters. So why so many rules, exceptions and experiments= ? Why don't we use byte_t keyword so it will at least fit with 2nd gene= ration types? If that is not possible I consider the new proposal so confus= ing to the users that it shouldn't be accepted. We live without it sinc= e the beginning anyway. What do the others here think?

--
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/7da80620-e4bd-40eb-a4ec-4f3c2dcb2c98= %40isocpp.org.
------=_Part_1717_1049496307.1477916900581-- ------=_Part_1716_1413286481.1477916900581-- .