220 27901 <7777451.RoO7Qxo2g3@tjmaciei-mobl1> article Path: news.gmane.org!.POSTED!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Stabilize the numeric types in all platforms Date: Tue, 23 Aug 2016 07:45:42 -0700 Lines: 59 Approved: news@gmane.org Message-ID: <7777451.RoO7Qxo2g3@tjmaciei-mobl1> References: <1706311.trY4MaExHO@tjmaciei-mobl1> <36958399-1282-4cef-a12b-0439e176aeda@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 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1471963561 2449 195.159.176.226 (23 Aug 2016 14:46:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 Aug 2016 14:46:01 +0000 (UTC) User-Agent: KMail/5.2.3 (Linux/4.6.4-2-default; KDE/5.24.0; x86_64; ; ) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBH6D6G6QKGQEAZ5V74I@isocpp.org Tue Aug 23 16:45:52 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f69.google.com ([74.125.82.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bcCxb-0008Ti-DV for gclcip-std-proposals@m.gmane.org; Tue, 23 Aug 2016 16:45:51 +0200 Original-Received: by mail-wm0-f69.google.com with SMTP id u81sf86404755wmu.3 for ; Tue, 23 Aug 2016 07:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version: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=8bPwYVTOT8fTs3YOETmzz1zvDn3jh5P5uKZA5vDn68s=; b=YJaGC91sAWSbG2c5EC84M/CQSnb7mlNwIOFp34rk+fRuXRcxYNPSUtBmihDYhA+1Rk 251vXnAA7kfxQlPAmxqGa3Os6VWfASHOvp7qsf2WI3szxUqdBsn4ep8zX3OUtfip/i0t NAauy9Bp8Ip1ZzJhdINRZBIxRhfO+B1so05kDIHo1qm+2RYdVcAbeUsZ+rVjtfTmcNaO SNLVFs9rXTWWSqm7yzbhciig58kYhsyxF6a/07SuHy+11qTA5UPogJiw7aaiua+39EkR qlNZZTXKZiVoFz6S/0P4KKQzj7u3yybFOvi6tEtvchqy4WEsMQbkjRHOVmuf6V63JNLA X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version: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=8bPwYVTOT8fTs3YOETmzz1zvDn3jh5P5uKZA5vDn68s=; b=i4vlm+FalFrPsrv58cf8aHhpCBXSEgsOAdE+92RxOg9PjrIQqCLMQ3O3FTZVwA9pVH XUdjgMPhDBFMI1cKuQzvi/Cz3TSfzvGWYs5jLPcyTtU5hwZoqZ/Duol3vCL85BNr7Av1 6MM2RPubRygtEYwrxi8Ee7YzVDLiOPD7OKx+/y+eHFsbe3pYtV7urbIp3LWkUCQNhe9/ p2yKr/9SbA21AQHAx8pqwK594MEmNevWLmAkOc8wRF5VjZXSovpb0MDA0pQfQ+kwHpzD J/xrsdHBnelkzcf6bpZl3UcByCvn4g6Qw6KyDxzGoQAXZI4gsL/4aGrrod4MAd7ryTNN X-Gm-Message-State: AEkoouv19xOGLGcc+Nw/UGt9diqSBPIrgNW7cViDrzPfap5yGkbR+E4h2K06A07X36sjVA== X-Received: by 10.194.2.227 with SMTP id 3mr3966578wjx.3.1471963552138; Tue, 23 Aug 2016 07:45:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.137.4 with SMTP id l4ls3274538wmd.26.gmail; Tue, 23 Aug 2016 07:45:50 -0700 (PDT) X-Received: by 10.28.206.8 with SMTP id e8mr19450598wmg.57.1471963550670; Tue, 23 Aug 2016 07:45:50 -0700 (PDT) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id i9si3391777wjg.122.2016.08.23.07.45.50 for ; Tue, 23 Aug 2016 07:45:50 -0700 (PDT) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl1.localnet (unknown [IPv6:2601:1c0:5803:81c9:f071:bb7f:b415:ad52]) by gondolin.macieira.info (Postfix) with ESMTPSA id B11CC11A1BA for ; Tue, 23 Aug 2016 07:45:49 -0700 (PDT) In-Reply-To: <36958399-1282-4cef-a12b-0439e176aeda@isocpp.org> X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org 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:27901 Archived-At: On ter=C3=A7a-feira, 23 de agosto de 2016 04:31:20 PDT FrankHB1989 wrote: > Good point about 2's complements. However, all of these are what I have= =20 > already known. I still wonder why these (at least partially) width-aware= =20 > types are not in the core language while traditional fundamental integer= =20 > types are still in it. In a systemic view of design, this is an=20 > inappropriate inversion of abstraction layers -- all implementations in= =20 > reality build these fundamental types on some integer types with known=20 > width provided by underlying specification, or just with the width=20 > specified artificially. Since we always will have some exact width intege= rs=20 > in the stacks of implementation, why not lift the uncertainty to the high= er > level? Though I don't think declaring `short` or `long` by users very > useful, but it gives us an opportunity to have the core language cleaner, > with less confusion, meeting better to the principle of zero-cost > abstraction mentally, and being a little easier to implement. > Or perhaps better keeping them all out of the core language? Like Nicol said, I don't see what the issue is about having to #include=20 something before you can use the types. I find that having the exact-width= =20 types *not* be reserved keywords is a better option, because it won't break= =20 code that has myNS::int32_t, nor code that was ABI-dependent but fully vali= d=20 that defined (and defines) int32_t in the global namespace. Moreover, as we've said time and again, the exact-width integer types aren'= t=20 required to exist in all implementations. Your statement saying "we will=20 always have some exact width integers" is incorrect. So what's the point of= =20 having a reserved word that can't be used? You may not think that using short or long is very useful, but others may= =20 disagree with you. I personally agree partially and disagree on other parts= ..=20 More to the point, changing the fundamental integer types now is a simple n= on- starter. Leave them alone. --=20 Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center --=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/7777451.RoO7Qxo2g3%40tjmaciei-mobl1. .