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
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! :-)
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
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
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
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
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
_Please_ keep the mail/nntp/... discussion separate or private.
It's clobbering the topic.
Thanks,
Johan
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
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
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
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*
.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
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
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
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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?
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
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
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
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:
>>>
>>>
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;
}
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
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 =
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
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
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
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
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
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
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
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
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
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,
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
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");
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
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
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
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
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
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?
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,
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
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
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
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
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
> >
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
> >
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
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
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*
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
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
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
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
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
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,
> [...]
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
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
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
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
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:
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
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
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
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
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.
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
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
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
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
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
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
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
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)?
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
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:
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
Even better yet:
byte b;
b = -b; // Deprecation error
WAT
T
--
All men are mortal. Socrates is mortal. Therefore all men are Socrates.
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:
/tmp/test.d(7): Deprecation: integral
95 matches
Mail list logo