Re: Annoyance with new integer promotion deprecations

On 19 February 2018 at 21:16, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > > On 02/19/2018 03:52 AM, Manu wrote: >> >> On 18 Feb. 2018 10:25 pm, "Walter Bright via Digitalmars-d" < >> digitalmars-d@puremagic.com> wrote: >> >> On 2/18/2018 7:52 PM, Nick

Re: Annoyance with new integer promotion deprecations

On 2/20/2018 6:23 AM, Steven Schveighoffer wrote: P.S. yes, Walter, I created a bugzilla for this :) https://issues.dlang.org/show_bug.cgi?id=18380 You da man, Steve! :-)

Re: Annoyance with new integer promotion deprecations

On 2/18/18 3:01 PM, Jonathan M Davis wrote: On Sunday, February 18, 2018 19:42:07 Johan Engelen via Digitalmars-d wrote: There are hundreds of lines I need to molest to make the compiler shut up. I won't type another line of code on my colour library until this noise is gone... I will not

Re: Annoyance with new integer promotion deprecations

On Tuesday, 20 February 2018 at 06:40:25 UTC, Tobias Müller wrote: It's no wonder that D has so few contributors if they are actively scared away. C'mon... was it really that scary? If you want more people to contribute, make it as easy for them as possible. and 'easy as possible' is

Re: Annoyance with new integer promotion deprecations

Nick Sabalausky (Abscissa) wrote: > On 02/19/2018 03:52 AM, Manu wrote: >> On 18 Feb. 2018 10:25 pm, "Walter Bright via Digitalmars-d" < >> digitalmars-d@puremagic.com> wrote: >> >> On 2/18/2018 7:52 PM, Nick Sabalausky (Abscissa) wrote: >> >>> Well, it's

Re: Annoyance with new integer promotion deprecations

On Monday, 19 February 2018 at 02:23:02 UTC, Walter Bright wrote: This one isn't double size. But google does insert some weird fields: Almost certainly, that 'wierd' stuff is related to googles insidious need to track and record EVERYTHING *you* do, so it can build an even better

Re: Annoyance with new integer promotion deprecations

On 02/19/2018 03:52 AM, Manu wrote: On 18 Feb. 2018 10:25 pm, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: On 2/18/2018 7:52 PM, Nick Sabalausky (Abscissa) wrote: Well, it's also the world's most inconsistant and statndards-disregarding. We're talking 1990's

Re: Annoyance with new integer promotion deprecations

_Please_ keep the mail/nntp/... discussion separate or private. It's clobbering the topic. Thanks, Johan

Re: Annoyance with new integer promotion deprecations

On Sunday, 18 February 2018 at 20:01:39 UTC, Jonathan M Davis wrote: On Sunday, February 18, 2018 19:42:07 Johan Engelen via Digitalmars-d wrote: > There are hundreds of lines I need to molest to make the > compiler shut up. I won't type another line of code on my > colour library until this

Re: Annoyance with new integer promotion deprecations

On 2/19/2018 12:52 AM, Manu wrote: On 18 Feb. 2018 10:25 pm, "Walter Bright via Digitalmars-d" > wrote: On 2/18/2018 7:52 PM, Nick Sabalausky (Abscissa) wrote: Well, it's also the world's most inconsistant and

Re: Annoyance with new integer promotion deprecations

to post to NNTP) does not do > that. Here's what the headers TB generates: > > - > Path: > digitalmars.com!.POSTED.c-73-83-17-42.hsd1.wa.comcast.net!not-for-mail > From: Walter Bright <newshou...@digitalmars.com> > Newsgroups: digita

Re: Annoyance with new integer promotion deprecations

On 18 Feb. 2018 10:25 pm, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: On 2/18/2018 7:52 PM, Nick Sabalausky (Abscissa) wrote: > Well, it's also the world's most inconsistant and statndards-disregarding. > We're talking 1990's MS-level behavior here. It's *always*

Re: Annoyance with new integer promotion deprecations

.com> Newsgroups: digitalmars.D Subject: Re: Annoyance with new integer promotion deprecations Date: Sun, 18 Feb 2018 22:17:49 -0800 Organization: Digital Mars Message-ID: <p6dq6b$4qh$1...@digitalmars.com> References: <20180205192225.ga30...@quickfur.ath.cx> <mailman.3774

Re: Annoyance with new integer promotion deprecations

On Sunday, February 18, 2018 22:17:49 Walter Bright via Digitalmars-d wrote: > On 2/18/2018 6:52 PM, Jonathan M Davis wrote: > > On Sunday, February 18, 2018 18:26:25 Walter Bright via Digitalmars-d wrote: > >> It's your mail client that is doing it. Not the NNTP software. > > > > As I pointed

Re: Annoyance with new integer promotion deprecations

On 2/18/2018 7:52 PM, Nick Sabalausky (Abscissa) wrote: Well, it's also the world's most inconsistant and statndards-disregarding. We're talking 1990's MS-level behavior here. It's *always* causing trouble for something or another. And the great thing about NNTP is that the user gets to

Re: Annoyance with new integer promotion deprecations

On 2/18/2018 6:52 PM, Jonathan M Davis wrote: On Sunday, February 18, 2018 18:26:25 Walter Bright via Digitalmars-d wrote: It's your mail client that is doing it. Not the NNTP software. As I pointed out in another post, mailman currently puts both the poster's e-mail address and the mailing

Re: Annoyance with new integer promotion deprecations

On 02/18/2018 08:34 PM, Manu wrote: Apparently gmail has a new trick... reply to thread == reply-all. That's never happened before. Can the forum software strip out the HTML if it detects it in the post? I'm astonished this isn't a bigger problem; surely gmail is the worlds most popular mail

Re: Annoyance with new integer promotion deprecations

On Sunday, February 18, 2018 18:26:25 Walter Bright via Digitalmars-d wrote: > > I find it kinda hard to accept responsibility here when I use the > > worlds most popular mail client in it's default configuration... This > > is a problem that should be fixed in the forum software. > > It's your

Re: Annoyance with new integer promotion deprecations

On 2/18/2018 5:39 PM, Manu wrote: Incidentally, why on earth are peoples personal email addresses even in the mail header? That's usually configurable. Most people set it so it's a fake address. It should be impossible for gmail to reply-all to peoples private emails, because they shouldn't

Re: Annoyance with new integer promotion deprecations

On 2/18/2018 5:34 PM, Manu wrote: Apparently gmail has a new trick... reply to thread == reply-all. That's never happened before. Can the forum software strip out the HTML if it detects it in the post? I'm astonished this isn't a bigger problem; surely gmail is the worlds most popular mail

Re: Annoyance with new integer promotion deprecations

On Sunday, February 18, 2018 15:52:45 Walter Bright via Digitalmars-d wrote: > Just replying to the n.g. would be fine, no need to cc me on email and cc > the mailing list. > > Also, your postings are double size again - html and plain text. Just the > plain text, please. I'm not sure who you're

Re: Annoyance with new integer promotion deprecations

On 18 February 2018 at 17:34, Manu wrote: > On 18 February 2018 at 15:52, Walter Bright via Digitalmars-d > wrote: >> >> Just replying to the n.g. would be fine, no need to cc me on email and cc >> the mailing list. >> >> Also, your postings are

Re: Annoyance with new integer promotion deprecations

On 18 February 2018 at 15:52, Walter Bright via Digitalmars-d wrote: > > Just replying to the n.g. would be fine, no need to cc me on email and cc the > mailing list. > > Also, your postings are double size again - html and plain text. Just the > plain text, please.

Re: Annoyance with new integer promotion deprecations

On 2/18/2018 1:17 PM, Martin Nowak wrote: Best solution, write a custom Int type that doesn't use C's horrible promotion rules. I've long wanted some SafeInt library that doesn't silently promote and supports saturation, overflow, and errors. Doesn't

Re: Annoyance with new integer promotion deprecations

Just replying to the n.g. would be fine, no need to cc me on email and cc the mailing list. Also, your postings are double size again - html and plain text. Just the plain text, please.

Re: Annoyance with new integer promotion deprecations

On 18 February 2018 at 13:17, Martin Nowak via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 02/18/2018 08:26 PM, Manu wrote: > > If change the behaviour (is done), then just let the code be broken! > > Emitting these terrible noises, and encouraging people to make their code > > even

Re: Annoyance with new integer promotion deprecations

On 02/18/2018 08:26 PM, Manu wrote: > If change the behaviour (is done), then just let the code be broken! > Emitting these terrible noises, and encouraging people to make their code > even noisier than the compiler output is much worse than broken code. > There are hundreds of lines I need to

Re: Annoyance with new integer promotion deprecations

On 18 February 2018 at 12:01, Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Sunday, February 18, 2018 19:42:07 Johan Engelen via Digitalmars-d > wrote: > > > There are hundreds of lines I need to molest to make the > > > compiler shut up. I won't type another line

Re: Annoyance with new integer promotion deprecations

On 18 February 2018 at 11:37, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 2/18/2018 11:21 AM, Guillaume Piolat wrote: > >> D used to not promote integer like C in the case of -short, -byte, ~ubyte >> etc. Which is a strange discrepancy as all other integer

Re: Annoyance with new integer promotion deprecations

On Sunday, February 18, 2018 19:42:07 Johan Engelen via Digitalmars-d wrote: > > There are hundreds of lines I need to molest to make the > > compiler shut up. I won't type another line of code on my > > colour library until this noise is gone... I will not maintain > > it. I am emotionally

Re: Annoyance with new integer promotion deprecations

On 2/18/2018 11:26 AM, Manu wrote: and most lines get 3-4 times longer because of these casts... I'm curious, can you please post an example?

Re: Annoyance with new integer promotion deprecations

On Sunday, 18 February 2018 at 19:26:43 UTC, Manu wrote: The 'solution' so add cast(int) and then cast back is not okay. I have code that does a lot of work on bytes/shorts (colour components are small integers that receive a lot of maths), and most lines get 3-4 times longer because of

Re: Annoyance with new integer promotion deprecations

On Sunday, February 18, 2018 11:26:43 Manu via Digitalmars-d wrote: > The 'solution' so add cast(int) and then cast back is not okay. I have > code that does a lot of work on bytes/shorts (colour components are small > integers that receive a lot of maths), and most lines get 3-4 times > longer

Re: Annoyance with new integer promotion deprecations

On 2/18/2018 11:21 AM, Guillaume Piolat wrote: D used to not promote integer like C in the case of -short, -byte, ~ubyte etc. Which is a strange discrepancy as all other integer arithmetic are the same. It was a bug, plain and simple. Whether it was always there, or was inadvertently

Re: Annoyance with new integer promotion deprecations

On 18 February 2018 at 05:36, Dmitry Olshansky via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Sunday, 18 February 2018 at 01:09:57 UTC, Manu wrote: > >> On 5 February 2018 at 11:22, H. S. Teoh via Digitalmars-d < >> digitalmars-d@puremagic.com> wrote: >> >> Code: >>> >>>

Re: Annoyance with new integer promotion deprecations

On Sunday, 18 February 2018 at 13:36:28 UTC, Dmitry Olshansky wrote: On Sunday, 18 February 2018 at 01:09:57 UTC, Manu wrote: On 5 February 2018 at 11:22, H. S. Teoh via Digitalmars-d < digitalmars-d@puremagic.com> wrote: Code: struct S { byte[2] x; }

Re: Annoyance with new integer promotion deprecations

On Sunday, 18 February 2018 at 01:09:57 UTC, Manu wrote: On 5 February 2018 at 11:22, H. S. Teoh via Digitalmars-d < digitalmars-d@puremagic.com> wrote: Code: struct S { byte[2] x; } void main() { S s, t; s.x = [ 1, -1

Re: Annoyance with new integer promotion deprecations

On 5 February 2018 at 11:22, H. S. Teoh via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > Code: > > struct S { > byte[2] x; > } > void main() { > S s, t; > s.x = [ 1, -1 ];// OK > t.x =

Re: Annoyance with new integer promotion deprecations

On 02/06/2018 05:38 PM, Luís Marques wrote: Yeah, it's annoying. For my MSP430 work (16-bit, lots of shorts and bytes) I created a generic type which works around this, so you would do: byte c = a.nx + b; where .nx means "non-extending" and converts/wraps the (u)byte/(u)short in my special

Re: Annoyance with new integer promotion deprecations

On Tuesday, 6 February 2018 at 20:23:02 UTC, Walter Bright wrote: [...] DFA is a complex thing. This is why DFA is done on the vastly simplified and canonicalized intermediate code, not the ASTs. Doing DFA for VRP means doing it on the ASTs. I know what you're asking for sounds simple

Re: Annoyance with new integer promotion deprecations

On Wednesday, 7 February 2018 at 11:30:02 UTC, Dominikus Dittes Scherkl wrote: Very cool! Much better than implementing new types. Just auto opBinary(string op, U)(NX!U rhs) { static if(rhs.value.sizeof > value.sizeof) return mixin("rhs " ~ op ~ " value"); That

Re: Annoyance with new integer promotion deprecations

On 2/6/18 8:06 PM, Luís Marques wrote: On Wednesday, 7 February 2018 at 00:24:26 UTC, H. S. Teoh wrote: I really like your .nx idea!  It neatly sidesteps the nonsensical mandatory casts and on top of that documents intent (the .nx being a telltale sign of truncation -- much better than

Re: Annoyance with new integer promotion deprecations

On Wednesday, 7 February 2018 at 01:06:42 UTC, Luís Marques wrote: On Wednesday, 7 February 2018 at 00:24:26 UTC, H. S. Teoh wrote: I really like your .nx idea! It neatly sidesteps the nonsensical mandatory casts and on top of that documents intent (the .nx being a telltale sign of truncation

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 20:45:22 UTC, H. S. Teoh wrote: On Mon, Feb 05, 2018 at 03:23:20PM -0500, Steven Schveighoffer via Digitalmars-d wrote: On 2/5/18 2:30 PM, H. S. Teoh wrote: > Even better yet: > > byte b; >b = -b; // Deprecation error > > WAT In the future, -b

Re: Annoyance with new integer promotion deprecations

On Wednesday, 7 February 2018 at 00:24:26 UTC, H. S. Teoh wrote: I really like your .nx idea! It neatly sidesteps the nonsensical mandatory casts and on top of that documents intent (the .nx being a telltale sign of truncation -- much better than arbitrary implicit rules). I think I'll adopt

Re: Annoyance with new integer promotion deprecations

On Tue, Feb 06, 2018 at 10:38:36PM +, Luís Marques via Digitalmars-d wrote: [...] > Yeah, it's annoying. For my MSP430 work (16-bit, lots of shorts and > bytes) I created a generic type which works around this, so you would > do: > > byte c = a.nx + b; > > where .nx means "non-extending" and

Re: Annoyance with new integer promotion deprecations

On Tue, Feb 06, 2018 at 12:23:02PM -0800, Walter Bright via Digitalmars-d wrote: > On 2/5/2018 10:08 PM, H. S. Teoh wrote: > > IMO, we should extend this past just one statement. It would lead to > > more possibilities for optimizations and possibly other features > > too. Though I understand

Re: Annoyance with new integer promotion deprecations

On Wed, Feb 07, 2018 at 12:10:14AM +, Adam D. Ruppe via Digitalmars-d wrote: > On Wednesday, 7 February 2018 at 00:00:05 UTC, Nick Sabalausky (Abscissa) > wrote: > > //pragma(msg, 3.14159.text); // Ugh, ok, floats don't work though :( > > So I saw a stb_sprintf with a from-scratch impl,

Re: Annoyance with new integer promotion deprecations

On Wednesday, 7 February 2018 at 00:00:05 UTC, Nick Sabalausky (Abscissa) wrote: //pragma(msg, 3.14159.text); // Ugh, ok, floats don't work though :( So I saw a stb_sprintf with a from-scratch impl, including floats, public domain. Someone on IRC was thinking about porting it. Maybe we

Re: Annoyance with new integer promotion deprecations

On 02/06/2018 01:22 AM, H. S. Teoh wrote: No need to wait for the future, you can do this today: enum toStr(alias X) = X.stringof; enum x = 100; pragma(msg, toStr!1); pragma(msg, toStr!3.14159); pragma(msg, "Hello " ~ toStr!10 ~ " world");

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 23:56:51 UTC, Adam D. Ruppe wrote: 1) Given: byte a, b; byte c = a + b; The cast seems a bit silly: you are already explicitly using `byte` everywhere, so your intention is pretty clear: you only want to use the bytes and are ok with the rest of it being

Re: Annoyance with new integer promotion deprecations

On 2/5/2018 10:08 PM, H. S. Teoh wrote: IMO, we should extend this past just one statement. It would lead to more possibilities for optimizations and possibly other features too. Though I understand that Walter has reservations about doing this for some reason. What you're asking for is data

Re: Annoyance with new integer promotion deprecations

On Mon, Feb 05, 2018 at 11:18:59PM -0800, Walter Bright via Digitalmars-d wrote: [...] > Except for 16 bit shorts. Shorts will exact a penalty :-) and so > shorts should only be used for data packing purposes. Really?! How so? T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius

Re: Annoyance with new integer promotion deprecations

On Tue, Feb 06, 2018 at 10:43:39AM +, Dominikus Dittes Scherkl via Digitalmars-d wrote: [...] > Every type should have a NAN value. For the signed types the extra > useless .min is a perfect candidate for a NAN. That allows -x to > always be of the same type as x, which I think is a good

Re: Annoyance with new integer promotion deprecations

On Tuesday, 6 February 2018 at 07:15:33 UTC, Walter Bright wrote: The thing is, when there are mixed integer sizes and signedness, there is no intuitive and correct solution. Each set of rules comes with its own set of cases where there are unintuitive behaviors. So, why doing any promotion

Re: Annoyance with new integer promotion deprecations

On Tuesday, 6 February 2018 at 07:18:59 UTC, Walter Bright wrote: Except for 16 bit shorts. Shorts will exact a penalty :-) and so shorts should only be used for data packing purposes. Which CPU model are you thinking of?

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 21:38:23 UTC, Simen Kjærås wrote: If you were negating a byte, the code does have compile-time known values, since there's a limit to what you can stuff into a byte. If you weren't, the warning is warranted. I will admit the case of -(-128) could throw it off,

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 23:18:58 UTC, Timon Gehr wrote: On 05.02.2018 22:56, Walter Bright wrote: It's necessary. Working C expressions cannot be converted to D while introducing subtle changes in behavior. ... Neither byte nor dchar are C types. The idea is a byte can be

Re: Annoyance with new integer promotion deprecations

On 2/5/2018 4:08 PM, Steven Schveighoffer wrote: I think the CPU has to do extra work to throw away that high bit, no? So much of software relies on C integer semantics that CPU vendors have optimized their performance for them, so no. Except for 16 bit shorts. Shorts will exact a penalty

Re: Annoyance with new integer promotion deprecations

On 2/5/2018 4:08 PM, Steven Schveighoffer wrote: In fact, this works in C: char a = 1; char b = 2; char c = a + b; I would actually have no problem if it were this way, as you are clear in your intention. I'm also OK with the way it is now, where it requires the cast. The cast is generally

Re: Annoyance with new integer promotion deprecations

On Tue, Feb 06, 2018 at 01:25:16AM +, Rubn via Digitalmars-d wrote: [...] > Maybe in the future this could be possible: > > static assert("Hello " ~ 10 ~ " world" == "Hello 10 world"); > > It'd help with CTFE code, I find having to convert integers to strings > a lot. This is cleaner syntax

Re: Annoyance with new integer promotion deprecations

On Tue, Feb 06, 2018 at 02:45:45AM +, Adam D. Ruppe via Digitalmars-d wrote: > On Tuesday, 6 February 2018 at 02:30:03 UTC, Walter Bright wrote: > > Maybe not, but casting back and forth between them is ugly. Pascal > > works this way, and it was one of the things I wound up hating about > >

Re: Annoyance with new integer promotion deprecations

On Mon, Feb 05, 2018 at 10:18:57PM -0500, Steven Schveighoffer via Digitalmars-d wrote: > On 2/5/18 10:05 PM, Nick Sabalausky (Abscissa) wrote: > > > Right, it wouldn't always get rid of the message, but I would think > > it should when it's known the value cannot be -128, such as the > >

Re: Annoyance with new integer promotion deprecations

I had filed that last week: https://issues.dlang.org/show_bug.cgi?id=18346 Issue 18346 - implicit conversion from int to char in `"foo" ~ 255` should be illegal we should deprecate it. On Mon, Feb 5, 2018 at 7:14 PM, Nick Sabalausky (Abscissa) via Digitalmars-d

Re: Annoyance with new integer promotion deprecations

On 2/5/18 10:05 PM, Nick Sabalausky (Abscissa) wrote: Right, it wouldn't always get rid of the message, but I would think it should when it's known the value cannot be -128, such as the specific example you posted. VRP is only for one statement. That is, once you get to the next statement

Re: Annoyance with new integer promotion deprecations

On 02/05/2018 09:30 PM, Walter Bright wrote: On 2/5/2018 3:18 PM, Timon Gehr wrote: The overloading rules are fine, but byte should not implicitly convert to char/dchar, and char should not implicitly convert to byte. Maybe not, but casting back and forth between them is ugly. It *should*

Re: Annoyance with new integer promotion deprecations

On Monday, February 05, 2018 18:30:03 Walter Bright via Digitalmars-d wrote: > On 2/5/2018 3:18 PM, Timon Gehr wrote: > > Neither byte nor dchar are C types. > > "byte" is a C "signed char". On Posix systems, a dchar maps to wchar_t, > although wchar_t is a typedef not a distinct type. It's a bit

Re: Annoyance with new integer promotion deprecations

On 02/05/2018 04:21 PM, H. S. Teoh wrote: On Mon, Feb 05, 2018 at 09:20:16PM +, Nick Sabalausky via Digitalmars-d wrote: But still, I thought we had value range propagation rules to avoid this sort of nonsense when possible (such as the example above)? VRP doesn't help when the code

Re: Annoyance with new integer promotion deprecations

On Tuesday, 6 February 2018 at 02:30:03 UTC, Walter Bright wrote: Maybe not, but casting back and forth between them is ugly. Pascal works this way, and it was one of the things I wound up hating about Pascal, all those ORD and CHR casts. It is a bit ironic hearing this from the guy who made

Re: Annoyance with new integer promotion deprecations

On 2/5/2018 3:18 PM, Timon Gehr wrote: Neither byte nor dchar are C types. "byte" is a C "signed char". On Posix systems, a dchar maps to wchar_t, although wchar_t is a typedef not a distinct type. It's a bit complicated :-) The overloading rules are fine, but byte should not implicitly

Re: Annoyance with new integer promotion deprecations

On Tuesday, 6 February 2018 at 01:07:21 UTC, Meta wrote: On Tuesday, 6 February 2018 at 00:18:08 UTC, Jonathan M Davis wrote: On Monday, February 05, 2018 15:27:45 H. S. Teoh via Digitalmars-d wrote: On Mon, Feb 05, 2018 at 01:56:33PM -0800, Walter Bright via Digitalmars-d wrote: > The idea

Re: Annoyance with new integer promotion deprecations

On Tuesday, 6 February 2018 at 00:18:08 UTC, Jonathan M Davis wrote: On Monday, February 05, 2018 15:27:45 H. S. Teoh via Digitalmars-d wrote: On Mon, Feb 05, 2018 at 01:56:33PM -0800, Walter Bright via Digitalmars-d wrote: > The idea is a byte can be implicitly converted to a dchar, > [...]

Re: Annoyance with new integer promotion deprecations

On 2/5/18 7:47 PM, Adam D. Ruppe wrote: On Tuesday, 6 February 2018 at 00:08:12 UTC, Steven Schveighoffer wrote: I think the CPU has to do extra work to throw away that high bit, no? No, the x86 has never had any trouble with this, and I don't think ARM does either (worst case you load it as

Re: Annoyance with new integer promotion deprecations

On Mon, Feb 05, 2018 at 07:08:12PM -0500, Steven Schveighoffer via Digitalmars-d wrote: > On 2/5/18 6:56 PM, Adam D. Ruppe wrote: [...] > > 2) Change it to: > >     byte a, b; > >     int c = a + b; > > > > This is directly analogous to the float example. Which, I agree, > > reasonable people

Re: Annoyance with new integer promotion deprecations

On Tuesday, 6 February 2018 at 00:08:12 UTC, Steven Schveighoffer wrote: I think the CPU has to do extra work to throw away that high bit, no? No, the x86 has never had any trouble with this, and I don't think ARM does either (worst case you load it as int, then save it as byte). I still

Re: Annoyance with new integer promotion deprecations

On Monday, February 05, 2018 15:27:45 H. S. Teoh via Digitalmars-d wrote: > On Mon, Feb 05, 2018 at 01:56:33PM -0800, Walter Bright via Digitalmars-d wrote: > > The idea is a byte can be implicitly converted to a dchar, [...] > > This is the root of the problem. Character types should never have

Re: Annoyance with new integer promotion deprecations

On 2/5/18 6:56 PM, Adam D. Ruppe wrote: On Monday, 5 February 2018 at 23:34:59 UTC, Steven Schveighoffer wrote: But for integer division and assignment to float, it's quite obvious that it doesn't work with almost all combinations. So let me take two steps there to get to my point: 1) Given:

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 23:34:59 UTC, Steven Schveighoffer wrote: But for integer division and assignment to float, it's quite obvious that it doesn't work with almost all combinations. So let me take two steps there to get to my point: 1) Given: byte a, b; byte c = a + b; The

Re: Annoyance with new integer promotion deprecations

On Mon, Feb 05, 2018 at 01:56:33PM -0800, Walter Bright via Digitalmars-d wrote: > On 2/5/2018 12:45 PM, H. S. Teoh wrote: > > Sticking to C promotion rules is one of the scourges that continue to > > plague D; > > It's necessary. Working C expressions cannot be converted to D while > introducing

Re: Annoyance with new integer promotion deprecations

On 2/5/18 6:09 PM, Adam D. Ruppe wrote: On Monday, 5 February 2018 at 22:52:41 UTC, Steven Schveighoffer wrote: But I can't see why there is controversy over negation of byte turning into an int. I can't see why anyone would expect: int x = -b; when b is -128, to set x to -128. The integer

Re: Annoyance with new integer promotion deprecations

On 05.02.2018 22:56, Walter Bright wrote: On 2/5/2018 12:45 PM, H. S. Teoh wrote: Sticking to C promotion rules is one of the scourges that continue to plague D; It's necessary. Working C expressions cannot be converted to D while introducing subtle changes in behavior. ... Neither byte

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 22:52:41 UTC, Steven Schveighoffer wrote: But I can't see why there is controversy over negation of byte turning into an int. I can't see why anyone would expect: int x = -b; when b is -128, to set x to -128. The integer promotion makes complete sense to me.

Re: Annoyance with new integer promotion deprecations

On 2/5/18 3:45 PM, H. S. Teoh wrote: On Mon, Feb 05, 2018 at 03:23:20PM -0500, Steven Schveighoffer via Digitalmars-d wrote: On 2/5/18 2:30 PM, H. S. Teoh wrote: Even better yet: byte b; b = -b; // Deprecation error WAT In the future, -b will be typed as an

Re: Annoyance with new integer promotion deprecations

On 2/5/18 3:21 PM, Steven Schveighoffer wrote: IMO, you shouldn't have to cast to int first, if you are just casting back to byte: int x = cast(byte)-b; assert(x == -128) // both with and without intpromote But I don't know if the compiler can be made to see this eventual result and not

Re: Annoyance with new integer promotion deprecations

On 2/5/2018 12:45 PM, H. S. Teoh wrote: Sticking to C promotion rules is one of the scourges that continue to plague D; It's necessary. Working C expressions cannot be converted to D while introducing subtle changes in behavior. another example is char -> byte confusion no thanks to C

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 21:25:41 UTC, Walter Bright wrote: The real bug is that VRP should allow this particular case. No, because of the byte.min case after promotion to int actually loses information. But the promotion to int suuucks. I gave this a lot of thought a few months

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 21:21:47 UTC, H. S. Teoh wrote: On Mon, Feb 05, 2018 at 09:20:16PM +, Nick Sabalausky via Digitalmars-d wrote: But still, I thought we had value range propagation rules to avoid this sort of nonsense when possible (such as the example above)? VRP doesn't

Re: Annoyance with new integer promotion deprecations

On Mon, Feb 05, 2018 at 09:20:16PM +, Nick Sabalausky via Digitalmars-d wrote: > Ouch. I guess "the real WTF" is that 2's complement leads to > supporting one value that cannot be negated. By that logic, we should issue the same warning for negating ints, but we don't. > But still, I

Re: Annoyance with new integer promotion deprecations

On 2/5/2018 1:20 PM, Nick Sabalausky wrote: Ouch. I guess "the real WTF" is that 2's complement leads to supporting one value that cannot be negated. But still, I thought we had value range propagation rules to avoid this sort of nonsense when possible (such as the example above)? The real

Re: Annoyance with new integer promotion deprecations

Ouch. I guess "the real WTF" is that 2's complement leads to supporting one value that cannot be negated. But still, I thought we had value range propagation rules to avoid this sort of nonsense when possible (such as the example above)?

Re: Annoyance with new integer promotion deprecations

On Mon, Feb 05, 2018 at 03:23:20PM -0500, Steven Schveighoffer via Digitalmars-d wrote: > On 2/5/18 2:30 PM, H. S. Teoh wrote: > > Even better yet: > > > > byte b; > > b = -b; // Deprecation error > > > > WAT > > In the future, -b will be typed as an int, so you can't

Re: Annoyance with new integer promotion deprecations

On 2/5/18 2:22 PM, H. S. Teoh wrote: Code: struct S { byte[2] x; } void main() { S s, t; s.x = [ 1, -1 ];// OK t.x = [ -s.x[0], -s.x[1] ]; // NG (line 7) } Compiler says:

Re: Annoyance with new integer promotion deprecations

On 2/5/18 2:30 PM, H. S. Teoh wrote: Even better yet: byte b; b = -b; // Deprecation error WAT In the future, -b will be typed as an int, so you can't reassign it to b. You can see this today with -transition=intpomote: Error: cannot implicitly convert

Re: Annoyance with new integer promotion deprecations

Even better yet: byte b; b = -b; // Deprecation error WAT T -- All men are mortal. Socrates is mortal. Therefore all men are Socrates.