Re: Annoyance with new integer promotion deprecations

[Manu via Digitalmars-d]

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 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 choose the client.
>> Not the server. If you don't like the way your client behaves, use another
>> one.
>>
>>
>> Except in this case it's you that doesn't like the way my mail client
>> behaves.
>>
>
> Because your mail client is BROKEN.

1. The mailing list shouldn't mail out peoples personal email
addresses. I shouldn't have had Walter's personal email address
anywhere near the reply-to field. All I did was click reply. If I was
subscribed to a mailing list that sent my private email address to all
recipients, I'd be very angry (I guess I am!).
2. It's completely normal for email clients (not just gmail) to send
the text + html version of emails. Outlook does it too. If the mailing
list/newsgroup synchroniser doesn't want the html it receives from
email clients, it could easily truncate it, and the problem would
cease to exist.

> Then petition *Google* to fix their shitty fucking software. You've already 
> been told it has fuck all to do with NNTP.
>
> Seriously, why the fuck would ANYONE think that by relying on Google software 
> they're somehow NOT being dragged along by the ear on Google's every whim and 
> misstep. Christ, we've already been through all this SAME EXACT shit in the 
> 90's with Microsoft, let's try actually *learning* from it and move on.

I'm not sure there's anything wrong with gmail here. It replied to
Walter's personal email because it was in the email header... that's
the bug, not my mail client. I'd say it's a critical privacy violation
bug too.
And emailing in HTML is the normal kind. Setting to plaintext is the
un-usual configuration, and it's not a gmail/outlook bug that I don't
change the mode. (it may be a gmail bug that the setting resets
occasionally though, I'm not sure why it resets from time to time)


If we don't want people to subscribe to the mailing list and use their
email clients to interact with the newsgroup, then don't offer the
mailing list: http://lists.puremagic.com/cgi-bin/mailman/listinfo/digitalmars-d
Just remove and disable it, and people won't use email clients. But
don't say it's invalid for people to use the interface provided in the
usual way with normal/overwhelming-common email clients in default
settings...

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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

[Steven Schveighoffer via Digitalmars-d]

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 maintain
it. I am emotionally incapable of assaulting my code with those
casts.


Using the `-transition=intpromote` compile flag is no option for
you?


Since that's a transition flag, it's really only a stop-gap solution. So, if
his issue is that he doesn't like having the casts in his code as opposed to
not wanting to deal with updating his code right now, the flag really
doesn't help.


No, -transition=intpromote is not stopgap, it's a flag to switch 
behavior to the new way. The stopgap is simply that you need to use the 
switch to get the new behavior (eventually, you will not need the 
switch). Everyone who is receiving these warnings should address each 
one, and THEN always compile their code with -transition=intpromote. 
Then, you may actually be able to remove some of the casts.


But you will still need casts in many cases.

However, there is one case where I think even without the intpromote 
flag is sent, that only a single cast should be necessary:


byte b = byte.min;

b = cast(byte)-b;

This is the same value whether you use intpromote or not. But this 
prints the deprecation unless you do:


b = cast(byte)-cast(int)b;

Which is awful.

-Steve

P.S. yes, Walter, I created a bugzilla for this :)
https://issues.dlang.org/show_bug.cgi?id=18380

Re: Annoyance with new integer promotion deprecations

[psychoticRabbit via Digitalmars-d]

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 already done for them - just use this 
forum as I do, from this website.


what is a nntp client anyway?

I think I recall using one back in the 90's...but that was so 
long ao...

Re: Annoyance with new integer promotion deprecations

[Tobias Müller via Digitalmars-d]

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 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 choose the client.
>> Not the server. If you don't like the way your client behaves, use another
>> one.
>> 
>> 
>> Except in this case it's you that doesn't like the way my mail client
>> behaves.
>> 
> 
> Because your mail client is BROKEN.
> 
>> I don't want to install software, I'll continue using Gmail, undoubtedly
>> the world's most popular mail client...
> 
> Then petition *Google* to fix their shitty fucking software. You've 
> already been told it has fuck all to do with NNTP.
> 
> Seriously, why the fuck would ANYONE think that by relying on Google 
> software they're somehow NOT being dragged along by the ear on Google's 
> every whim and misstep. Christ, we've already been through all this SAME 
> EXACT shit in the 90's with Microsoft, let's try actually *learning* 
> from it and move on.

It's no wonder that D has so few contributors if they are actively scared
away.

If you want more people to contribute, make it as easy for them as
possible. I really don't understand why this cannot be solved on the
server. Replying to all adresses in the Reply-To: header isn't what I would
call broken anyway. Is he even using NNTP? Or maybe the mailing list
Interface?

Re: Annoyance with new integer promotion deprecations

[psychoticRabbit via Digitalmars-d]

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 profile of you (usually without you even 
knowing it does so), and then, having achieved this objective, it 
switches to it primary objective : to throw even more targeted 
advertising at you.


The human race has become nothing more than fodder for targetted 
advertising.


See... that's the mistake Microsoft made in the 80s and 90s - 
they just didn't understood the psychology of the gift economy, 
and how to manipulate it, and profit from it.


That's the only reason why we're discussing Google mail instead 
of Microsoft mail.

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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 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 choose the client.
Not the server. If you don't like the way your client behaves, use another
one.


Except in this case it's you that doesn't like the way my mail client
behaves.



Because your mail client is BROKEN.


I don't want to install software, I'll continue using Gmail, undoubtedly
the world's most popular mail client...


Then petition *Google* to fix their shitty fucking software. You've 
already been told it has fuck all to do with NNTP.


Seriously, why the fuck would ANYONE think that by relying on Google 
software they're somehow NOT being dragged along by the ear on Google's 
every whim and misstep. Christ, we've already been through all this SAME 
EXACT shit in the 90's with Microsoft, let's try actually *learning* 
from it and move on.

Re: Annoyance with new integer promotion deprecations

[Johan Engelen via Digitalmars-d]

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


Thanks,
  Johan

Re: Annoyance with new integer promotion deprecations

[Johan Engelen via Digitalmars-d]

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 noise is gone... I will not 
> maintain it. I am emotionally incapable of assaulting my 
> code with those casts.


Using the `-transition=intpromote` compile flag is no option 
for you?


Since that's a transition flag, it's really only a stop-gap 
solution. So, if his issue is that he doesn't like having the 
casts in his code as opposed to not wanting to deal with 
updating his code right now, the flag really doesn't help.


I thought Manu explicitly mentioned that he'd rather have 
possible code breakage than the deprecation message. I'm assuming 
in his case there will not be any breakage. Using 
`-transition=intpromote` will change to the C semantics and shuts 
up the deprecation messages. With time the semantics of 
`-transition=intpromote` will become the new default and the flag 
is no longer needed. So the flag is very helpful in avoiding 
having to adjust the code.


I'd say that if he's not going to abandon his library, he 
either needs to just grit his teeth and use the explicit casts, 
or he's going to need to refactor the code so that the casts 
are unnecessary.


I don't see how one would refactor `ubyte foo(ubyte a) { return 
-a; }` and improve things.


-Johan

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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
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 choose the client.
Not the server. If you don't like the way your client behaves, use another 
one.


Except in this case it's you that doesn't like the way my mail client behaves.


You're right, I don't like that your mail client sends me private email for 
every forum reply you make to me. This is NOTHING to do with NNTP or the forum 
software. It's YOUR mail client.


There's nothing I nor anyone here can do about your mail client.


I don't want to install software, I'll continue using Gmail, undoubtedly the 
world's most popular mail client... I feel like this client should be well 
supported by the forum software, and not cause problems in its default settings 
(which it seems to revert to frequently... Maybe they update?)


The D forum software has nothing to do with how you configure YOUR email client.

Note that you can use DFeed itself to interact with the newsgroup. You don't 
have to install anything to do that.

Re: Annoyance with new integer promotion deprecations

[Jonathan M Davis via Digitalmars-d]

On Monday, February 19, 2018 00:36:11 Walter Bright via Digitalmars-d wrote:
> On 2/18/2018 11:02 PM, Jonathan M Davis wrote:
> > On Sunday, February 18, 2018 22:17:49 Walter Bright via Digitalmars-d 
wrote:
> >> But that's still the mail client, not the NNTP software.
> >
> > It's a problem with how mailman is configured. Yes, the user can remove
> > the second e-mail address from "To" when replying, but that's easy to
> > miss, and as I understand it, the e-mail client is doing the correct
> > thing when it puts all of the addresses in the "Reply-To" header in
> > "To" when responding. Mailman shouldn't be putting two address in the
> > "Reply-To" field if the first place, and if didn't, then this wouldn't
> > be a problem.
> >
> > And no, that's not a problem with NNTP, but it's a problem with the
> > interface that many of us use to interact with the newsgroup, and it's
> > not a problem with the clients that we're running ourselves to read and
> > send e-mail to the mailing list.
>
> Just to let you know, Thunderbird (what I use 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: 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.1519004362.9493.digitalmar...@puremagic.com>
>   <p6dckf$1t3u$1...@digitalmars.com>
>   <mailman.3777.1519008737.9493.digitalmar...@puremagic.com>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Transfer-Encoding: 7bit
> Injection-Date: Mon, 19 Feb 2018 06:17:47 + (UTC)
> Injection-Info: digitalmars.com;
> posting-host="c-73-83-17-42.hsd1.wa.comcast.net:73.83.17.42";
>   logging-data="4945"; mail-complaints-to="use...@digitalmars.com"
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>   Thunderbird/52.6.0
> In-Reply-To: <mailman.3777.1519008737.9493.digitalmar...@puremagic.com>
> Content-Language: en-US
> Xref: digitalmars.com digitalmars.D:311870
> ---
>
> Note that the [From:] email address shown is configurable in TB. It
> doesn't have to be a real address.

Well, I don't use NNTP, and when your message arrived from the mailing list,
it had this in its headers:

Reply-To: Walter Bright <newshou...@digitalmars.com>,
"digitalmars.D" <digitalmars-d@puremagic.com>

So, regardless of what you send via NNTP, mailman is sending a Reply-To with
your e-mail address in addition to the mailing list address, and that's
what's causing the problem. So, anyone who's using the newsgroup / mailing
list / forum via the mailing list interface is going to have this problem
regardless of what their e-mail client is and regardless of what client or
interface the person sending the message used. The only way someone using
the mailing list wouldn't have a problem would be if their e-mail client
ignored the Reply-To header and used the From header to decide which e-mail
address to reply to, which would be incorrect behavior for an e-mail client.

As long as mailman is sending both addresses in the Reply-To header instead
of just the mailing list's e-mail address, anyone using the mailing list
interface is going to be sending e-mails to both the mailing list and the
person they're replying to unless they manually remove the person's address
from the To field before sending the message.

The only solution that I see is for Brad to adjust mailman's configuration
so that it stops putting the poster's e-mail address in the Reply-To header.

- Jonathan M Davis

Re: Annoyance with new integer promotion deprecations

[Manu via Digitalmars-d]

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* causing trouble
> for something or another.
>

And the great thing about NNTP is that the user gets to choose the client.
Not the server. If you don't like the way your client behaves, use another
one.


Except in this case it's you that doesn't like the way my mail client
behaves.

I don't want to install software, I'll continue using Gmail, undoubtedly
the world's most popular mail client... I feel like this client should be
well supported by the forum software, and not cause problems in its default
settings (which it seems to revert to frequently... Maybe they update?)

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

On 2/18/2018 11:02 PM, Jonathan M Davis wrote:

On Sunday, February 18, 2018 22:17:49 Walter Bright via Digitalmars-d wrote:

But that's still the mail client, not the NNTP software.


It's a problem with how mailman is configured. Yes, the user can remove the
second e-mail address from "To" when replying, but that's easy to miss, and
as I understand it, the e-mail client is doing the correct thing when it
puts all of the addresses in the "Reply-To" header in "To" when responding.
Mailman shouldn't be putting two address in the "Reply-To" field if the
first place, and if didn't, then this wouldn't be a problem.

And no, that's not a problem with NNTP, but it's a problem with the
interface that many of us use to interact with the newsgroup, and it's not a
problem with the clients that we're running ourselves to read and send
e-mail to the mailing list.


Just to let you know, Thunderbird (what I use 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: 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.1519004362.9493.digitalmar...@puremagic.com>
 <p6dckf$1t3u$1...@digitalmars.com>
 <mailman.3777.1519008737.9493.digitalmar...@puremagic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 19 Feb 2018 06:17:47 + (UTC)
Injection-Info: digitalmars.com; 
posting-host="c-73-83-17-42.hsd1.wa.comcast.net:73.83.17.42";

logging-data="4945"; mail-complaints-to="use...@digitalmars.com"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
In-Reply-To: <mailman.3777.1519008737.9493.digitalmar...@puremagic.com>
Content-Language: en-US
Xref: digitalmars.com digitalmars.D:311870
---

Note that the [From:] email address shown is configurable in TB. It doesn't have 
to be a real address.

Re: Annoyance with new integer promotion deprecations

[Jonathan M Davis via Digitalmars-d]

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 out in another post, mailman currently puts both the
> > poster's e-mail address and the mailing list's e-mail address in the
> > "Reply-To" field (whereas it it used to just put the mailing list's
> > e-mail address in there), which means that at least some e-mail clients
> > end up replying to both of those by default (and if I understand the
> > "Reply-To" field correctly, they're technically supposed to reply to
> > both by default if they're both in that field). I don't know why it's
> > putting both in there, but it's been doing it for a few months now
> > since about the time that Brad said that he was making changes to the
> > server (maybe an upgrade? I don't remember right now). So presumably,
> > something he did resulted in a change in how mailman acts, and if Manu
> > is using gmail, then that would presumably affect him.
>
> But that's still the mail client, not the NNTP software.

It's a problem with how mailman is configured. Yes, the user can remove the
second e-mail address from "To" when replying, but that's easy to miss, and
as I understand it, the e-mail client is doing the correct thing when it
puts all of the addresses in the "Reply-To" header in "To" when responding.
Mailman shouldn't be putting two address in the "Reply-To" field if the
first place, and if didn't, then this wouldn't be a problem.

And no, that's not a problem with NNTP, but it's a problem with the
interface that many of us use to interact with the newsgroup, and it's not a
problem with the clients that we're running ourselves to read and send
e-mail to the mailing list.

- Jonathan M Davis

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 choose the client. Not 
the server. If you don't like the way your client behaves, use another one. (I 
use Thunderbird.) You can also use DFeed as a client.


Nobody makes anyone use gmail or mailman to post to the forums.

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 list's e-mail address in the "Reply-To" field
(whereas it it used to just put the mailing list's e-mail address in there),
which means that at least some e-mail clients end up replying to both of
those by default (and if I understand the "Reply-To" field correctly,
they're technically supposed to reply to both by default if they're both in
that field). I don't know why it's putting both in there, but it's been
doing it for a few months now since about the time that Brad said that he
was making changes to the server (maybe an upgrade? I don't remember right
now). So presumably, something he did resulted in a change in how mailman
acts, and if Manu is using gmail, then that would presumably affect him.


But that's still the mail client, not the NNTP software.

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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 client, by like, 50x...?


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.

Re: Annoyance with new integer promotion deprecations

[Jonathan M Davis via Digitalmars-d]

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 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 list's e-mail address in the "Reply-To" field
(whereas it it used to just put the mailing list's e-mail address in there),
which means that at least some e-mail clients end up replying to both of
those by default (and if I understand the "Reply-To" field correctly,
they're technically supposed to reply to both by default if they're both in
that field). I don't know why it's putting both in there, but it's been
doing it for a few months now since about the time that Brad said that he
was making changes to the server (maybe an upgrade? I don't remember right
now). So presumably, something he did resulted in a change in how mailman
acts, and if Manu is using gmail, then that would presumably affect him.

- Jonathan M Davis

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 be anywhere in the
message to begin with.
I'd be pretty upset that the forum is leaking personal details like
that... sharing your private email in a public channel is a choice
that should be left to each user, and carefully controlled.

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 mail client that is doing it. Not the NNTP software.

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 client, by like, 50x...? How can this not
happen to everyone?


This one isn't double size. But google does insert some weird fields:


DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
 bh=uRnYxUnUqmBjolFz8BGw0rb19dar5NAVHmYt4O5Qu80=;
 b=N7vt7Lb7aw71aDIVW2X9znxGpG0LinWSOPlbUShMI8cOgsZZl8qRrPPKXJSPyzatsU
 lOEGd04g0eAvh6rC2BLy7IeBgOukAZKmLRPd2VPBN/tPSre44i5Ft2gVy9WOoUZ3ADwL
 lfXVf814QbLinLY/4s6pilDcgioI4NESbq3NWSKSCqFt5OjeXSAbKZoZ+IqyUOZVIPhj
 wAV1pdEkfXV4jXGDxp7fVZLLxu+3KGhh174467DyM7lPL1L1Tcx0iuHNX8csDGLu5Amb
 IS+dMkM3HgFUq5UvVaz4aC/+3g2K8oRXgwbZaFTnq3soo/QdJPMui8n2EhH6W9sX/1ru
 gjfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to;
 bh=uRnYxUnUqmBjolFz8BGw0rb19dar5NAVHmYt4O5Qu80=;
 b=HRMHYODhm6nr3ZbKHwBz/ksGv7/5itF1J7XVPm1+exgT7fdkcIFhfvshEs2zI47G2v
 mCibIz6tTuX/JsAi2nFr68tnlUPoYnH4FjzCalIgWUu66OMAzyXb0wREdnugpr/H2o5o
 icbcmryd8vpopq2ExZJZmUCRG3Lj0BWfKCjreLvDt1+wB/AkglCs7bLvFXLT6Qsi+40m
 vgktPToHG6mIEFNnc1WjMQaTXqFc7K293uA5V+ArGyX1oYDko40nmW+6isuuViJHnMn/
 +bW+qV46t7hxRJ5gmFqzNUg6l7gCowixW+1rh6hfk+Y/WlKXDwmaoLUKQsEyYPpKtr4l
 BQvA==
X-Gm-Message-State: APf1xPDTCadBH42vydQyqUn/yvW+9JOLERdPz9VDD7JkdgBZmXFBRLj6
 542UK0li9ZoD1VMBYYIqG4rYvd+6qHXlIqe1iuY=
X-Google-Smtp-Source: 
AH8x227v+Vglv6lH88YUlqDZkH4UjMc5El1y8ssuwpEGzR+3bXK/+Ts50qYRo2ULOrFvdlH+vF10fQOdCIBgmY4wiHk=

Re: Annoyance with new integer promotion deprecations

[Jonathan M Davis via Digitalmars-d]

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 replying to, since you failed to quote the original
message, and my e-mail reader frequently puts posts in the wrong place in
threads, but several months ago, after Brad made a change to the mail list
stuff, the "Reply-To" header was changed to list both the e-mail address of
the person who sent the message and the maling list's e-mail address. This
means that my e-mail client (and probably others) now defaults to sending
e-mails to both those e-mail addresses when I reply to a message in the
mailing list, and I constantly have to manually remove the personal e-mail
address of the poster from the "To" field so that I only e-mail the mailing
list rather than sending to both the mailing list and the person directly.
So, if I or whoever you're replying to is sending you an e-mail in addition
to sending it to the mailing list, I suspect that that's why.

I sent a message to Brad about it when I noticed it and figured out what was
happening, but either he never saw it, or he decided not to change it for
whatever reason.

- Jonathan M Davis

Re: Annoyance with new integer promotion deprecations

[Manu via Digitalmars-d]

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 double size again - html and plain text. Just the 
>> plain text, please.
>
>
> 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 client, by like, 50x...? How can this not
> happen to everyone?

Incidentally, why on earth are peoples personal email addresses even
in the mail header? It should be impossible for gmail to reply-all to
peoples private emails, because they shouldn't be anywhere in the
message to begin with.
I'd be pretty upset that the forum is leaking personal details like
that... sharing your private email in a public channel is a choice
that should be left to each user, and carefully controlled.

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.

Re: Annoyance with new integer promotion deprecations

[Manu via Digitalmars-d]

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.


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 client, by like, 50x...? How can this not
happen to everyone?

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 https://dlang.org/phobos/std_experimental_checkedint.html do that? It 
supports saturation, overflow, errors, and has hooks for operators.

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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

[Manu via Digitalmars-d]

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 noisier than the compiler output is much worse than broken code.
> > 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 incapable of assaulting
> my
> > code with those casts.
>
> 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.
>

That's pretty much what this particular code implements ;)

Re: Annoyance with new integer promotion deprecations

[Martin Nowak via Digitalmars-d]

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 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 incapable of assaulting my
> code with those casts.

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.

-Martin

Re: Annoyance with new integer promotion deprecations

[Manu via Digitalmars-d]

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 of code on my
> > > colour library until this noise is gone... I will not maintain
> > > it. I am emotionally incapable of assaulting my code with those
> > > casts.
> >
> > Using the `-transition=intpromote` compile flag is no option for
> > you?
>
> Since that's a transition flag, it's really only a stop-gap solution. So,
> if
> his issue is that he doesn't like having the casts in his code as opposed
> to
> not wanting to deal with updating his code right now, the flag really
> doesn't help.
>
> I'd say that if he's not going to abandon his library, he either needs to
> just grit his teeth and use the explicit casts, or he's going to need to
> refactor the code so that the casts are unnecessary.
>
> - Jonathan M Davis
>

Here's one file for instance (they all do this, although I can rearrange
the noise somewhat):

std\experimental\normint.d(526,24): Deprecation: integral promotion not
done for `-convertNormBits(((v ^ 512u) == 0u ? ~v : -v) & 511u)`, use
'-transition=intpromote' switch or `-cast(int)(convertNormBits(((v ^ 512u)
== 0u ? ~v : -v) & 511u))`
std\experimental\normint.d(526,119): Deprecation: integral promotion not
done for `~v`, use '-transition=intpromote' switch or `~cast(int)(v)`
std\experimental\normint.d(526,124): Deprecation: integral promotion not
done for `-v`, use '-transition=intpromote' switch or `-cast(int)(v)`
std\experimental\normint.d-mixin-78(78,1): Deprecation: integral promotion
not done for `+this.value`, use '-transition=intpromote' switch or
`+cast(int)(this.value)`
std\experimental\normint.d-mixin-78(78,1): Deprecation: integral promotion
not done for `-this.value`, use '-transition=intpromote' switch or
`-cast(int)(this.value)`
std\experimental\normint.d-mixin-78(78,1): Deprecation: integral promotion
not done for `~this.value`, use '-transition=intpromote' switch or
`~cast(int)(this.value)`
std\experimental\normint.d-mixin-78(78,1): Deprecation: integral promotion
not done for `~this.value`, use '-transition=intpromote' switch or
`~cast(int)(this.value)`
std\experimental\normint.d-mixin-78(78,1): Deprecation: integral promotion
not done for `-this.value`, use '-transition=intpromote' switch or
`-cast(int)(this.value)`
std\experimental\normint.d(526,119): Deprecation: integral promotion not
done for `~v`, use '-transition=intpromote' switch or `~cast(int)(v)`
std\experimental\normint.d(526,124): Deprecation: integral promotion not
done for `-v`, use '-transition=intpromote' switch or `-cast(int)(v)`
std\experimental\normint.d(526,24): Deprecation: integral promotion not
done for `-convertNormBits(cast(ubyte)(((cast(int)v ^ 128) == 0 ?
cast(int)~v : cast(int)-v) & 127))`, use '-transition=intpromote' switch or
`-cast(int)(convertNormBits(cast(ubyte)(((cast(int)v ^ 128) == 0 ?
cast(int)~v : cast(int)-v) & 127)))`
std\experimental\normint.d(526,119): Deprecation: integral promotion not
done for `~v`, use '-transition=intpromote' switch or `~cast(int)(v)`
std\experimental\normint.d(526,124): Deprecation: integral promotion not
done for `-v`, use '-transition=intpromote' switch or `-cast(int)(v)`
std\experimental\normint.d(526,24): Deprecation: integral promotion not
done for `-convertNormBits(cast(ushort)(((cast(int)v ^ 32768) == 0 ?
cast(int)~v : cast(int)-v) & 32767))`, use '-transition=intpromote' switch
or `-cast(int)(convertNormBits(cast(ushort)(((cast(int)v ^ 32768) == 0 ?
cast(int)~v : cast(int)-v) & 32767)))`
std\experimental\normint.d(526,24): Deprecation: integral promotion not
done for `-convertNormBits(((v ^ 2u) == 0u ? ~v : -v) & 1u)`, use
'-transition=intpromote' switch or `-cast(int)(convertNormBits(((v ^ 2u) ==
0u ? ~v : -v) & 1u))`
std\experimental\normint.d(526,24): Deprecation: integral promotion not
done for `-convertNormBits(((v ^ 4u) == 0u ? ~v : -v) & 3u)`, use
'-transition=intpromote' switch or `-cast(int)(convertNormBits(((v ^ 4u) ==
0u ? ~v : -v) & 3u))`
std\experimental\normint.d-mixin-78(78,1): Deprecation: integral promotion
not done for `+this.value`, use '-transition=intpromote' switch or
`+cast(int)(this.value)`
std\experimental\normint.d(526,119): Deprecation: integral promotion not
done for `~v`, use '-transition=intpromote' switch or `~cast(int)(v)`
std\experimental\normint.d(526,124): Deprecation: integral promotion not
done for `-v`, use '-transition=intpromote' switch or `-cast(int)(v)`
std\experimental\normint.d(526,24): Deprecation: integral promotion not
done for `-convertNormBits(cast(const(ubyte))(((cast(int)v ^ 128) == 0 ?
cast(int)~v : cast(int)-v) & 127))`, use '-transition=intpromote' switch or
`-cast(int)(convertNormBits(cast(const(ubyte))(((cast(int)v ^ 128) == 0 ?
cast(int)~v : cast(int)-v) & 127)))`

Re: Annoyance with new integer promotion deprecations

[Manu via Digitalmars-d]

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 arithmetic are the
>> same.
>>
>
> It was a bug, plain and simple. Whether it was always there, or was
> inadvertently introduced at some point, I don't know.
>

I'm complaining about the deprecation messages.

Re: Annoyance with new integer promotion deprecations

[Jonathan M Davis via Digitalmars-d]

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 incapable of assaulting my code with those
> > casts.
>
> Using the `-transition=intpromote` compile flag is no option for
> you?

Since that's a transition flag, it's really only a stop-gap solution. So, if
his issue is that he doesn't like having the casts in his code as opposed to
not wanting to deal with updating his code right now, the flag really
doesn't help.

I'd say that if he's not going to abandon his library, he either needs to
just grit his teeth and use the explicit casts, or he's going to need to
refactor the code so that the casts are unnecessary.

- Jonathan M Davis

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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

[Johan Engelen via Digitalmars-d]

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 these casts...
I can't accept that.

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.


Silently breaking code by changing language semantics is not an 
option; we do that accidentally sometimes and it makes upgrading 
to a newer compiler very very hard on large codebases. Let's 
cherish the few users of D in production code. The deprecation 
messages are annoying perhaps, but necessary.


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 incapable of assaulting my code with those 
casts.


Using the `-transition=intpromote` compile flag is no option for 
you?


- Johan

Re: Annoyance with new integer promotion deprecations

[Jonathan M Davis via Digitalmars-d]

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 because of these casts...
> I can't accept that.
>
> 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 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 incapable of
> assaulting my code with those casts.

You could always create a wrapper type that does the casts for you. IIRC,
someone already discussed a solution like that in this thread in order to
make (u)byte and (u)short arithmetic more pleasant even without the recent
changes. I suspect that if you're doing a lot of arithmetic on (u)bytes or
(u)shorts, that eventually becomes pretty much the only way to maintain your
sanity - and it could be made to add runtime checks for overflow if that was
desired instead of just making the compiler shut up. Then, it could become a
runtime check instead of a blunt compile-time check if that's what's
preferred.

All in all though, this is one of those areas where trying to make it so
that C code is either valid D code with the same semantics, or it doesn't
compile gets ugly.

I suspect that the vast majority of programmers will rarely be affected by
this, because most code doesn't need to do anything with (u)bytes or
(u)shorts, but if you have a use case where you're doing a lot with them,
then I can certainly see why it would get _really_ annoying.

- Jonathan M Davis

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 introduced at some point, I don't know.

Re: Annoyance with new integer promotion deprecations

[Manu via Digitalmars-d]

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:
>>>
>>> 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 promotion not done for
>>> `-s.x[0]`, use '-transition=intpromote' switch or `-cast(int)(s.x[0])`
>>> /tmp/test.d(7): Deprecation: integral promotion not done for
>>> `-s.x[1]`, use '-transition=intpromote' switch or `-cast(int)(s.x[1])`
>>>
>>>
>>> Why should I need to explicitly cast to int only to reassign it back to
>>> byte?!  This is ridiculous.
>>>
>>
>>
>> Seriously, WTF is going on here?
>>
>
> C compilers did it for ages, but D doesn’t auto promote to int on unary
> ops. Hence the warning, the suggestion is kinda stupid thiugh.
>
> C gets away by truncating results silently on assign of int to byte


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 these casts...
I can't accept that.

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 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 incapable of assaulting my
code with those casts.

Re: Annoyance with new integer promotion deprecations

[Guillaume Piolat via Digitalmars-d]

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;
}
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 promotion not 
done for
`-s.x[0]`, use '-transition=intpromote' switch or 
`-cast(int)(s.x[0])`
/tmp/test.d(7): Deprecation: integral promotion not 
done for
`-s.x[1]`, use '-transition=intpromote' switch or 
`-cast(int)(s.x[1])`



Why should I need to explicitly cast to int only to reassign 
it back to byte?!  This is ridiculous.



Seriously, WTF is going on here?


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.


I'm surprised by the number of complaints, what do you prefer:
- explain until the end of times that D has the same integer 
promotion that C, except for one edge case with unary ops and 
smaller integers? and have translated C code have subtle bugs.

- add a cast here and there for some years

Re: Annoyance with new integer promotion deprecations

[Dmitry Olshansky via Digitalmars-d]

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 ];// OK
t.x = [ -s.x[0], -s.x[1] ]; // NG (line 7)
}


Compiler says:
/tmp/test.d(7): Deprecation: integral promotion not 
done for
`-s.x[0]`, use '-transition=intpromote' switch or 
`-cast(int)(s.x[0])`
/tmp/test.d(7): Deprecation: integral promotion not 
done for
`-s.x[1]`, use '-transition=intpromote' switch or 
`-cast(int)(s.x[1])`



Why should I need to explicitly cast to int only to reassign 
it back to byte?!  This is ridiculous.



Seriously, WTF is going on here?


C compilers did it for ages, but D doesn’t auto promote to int on 
unary ops. Hence the warning, the suggestion is kinda stupid 
thiugh.


C gets away by truncating results silently on assign of int to 
byte.

Re: Annoyance with new integer promotion deprecations

[Manu via Digitalmars-d]

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 = [ -s.x[0], -s.x[1] ]; // NG (line 7)
> }
>
>
> Compiler says:
> /tmp/test.d(7): Deprecation: integral promotion not done for
> `-s.x[0]`, use '-transition=intpromote' switch or `-cast(int)(s.x[0])`
> /tmp/test.d(7): Deprecation: integral promotion not done for
> `-s.x[1]`, use '-transition=intpromote' switch or `-cast(int)(s.x[1])`
>
>
> Why should I need to explicitly cast to int only to reassign it back to
> byte?!  This is ridiculous.


Seriously, WTF is going on here?

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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 type. The arithmetic operations are infectious, so you 
only need to apply it to one of the operands (and you can preserve it 
across statements by using "auto" instead of "byte").


Very cool. Would love to see this as a dub package.

Re: Annoyance with new integer promotion deprecations

[Stefan Koch via Digitalmars-d]

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 enough. But it 
ain't.


What you're saying is true.
There is a way though to have the cake and eat it.
If IR keeps a backwards-transform to the AST, (whereby I mean the 
semantically-augmented tree closest to the actual AST).


It is possible to transfer insight gained further in the 
processing to earlier constructs.

Making it possible to extend VRP.

This might negativity impact compile-times, and it (maybe) won't 
be simple to implement.

Re: Annoyance with new integer promotion deprecations

[Luís Marques via Digitalmars-d]

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 won't do anything good for operators that are NOT 
commutative

(like -, ^^, <<, >>, %, /, ...)
Seems you don't use other things than +, *, &, | and ^, do you?


Ahah! That "fix" was only a temporary workaround for a unittest. 
In my actual code the rhs is always a T, not a NX!U, so it didn't 
matter. I forgot to remove that kludge before I copy pasted it 
here :-)

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer via Digitalmars-d]

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 arbitrary implicit 
rules).  I think I'll adopt it in some form in my code, to make 
dealing with narrow ints saner.  I don't know what your .nx type does, 
but for my purposes I'll probably just have a thin wrapper around 
byte/ubyte/etc. with overloaded arithmetic operators that perform the 
requisite casts.


Yeah, it's just a thin wrapper. I implemented just enough to cover my 
use cases but just in case it's useful to you or someone else, here goes 
my implementation...


private struct NX(T)
{

...


I think this would be a good Phobos addition. std.typecons?

-Steve

Re: Annoyance with new integer promotion deprecations

[Dominikus Dittes Scherkl via Digitalmars-d]

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 -- much 
better than arbitrary implicit rules).

[...]
Yeah, it's just a thin wrapper. I implemented just enough to 
cover my use cases but just in case it's useful to you or 
someone else, here goes my implementation...


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 won't do anything good for operators that are NOT commutative
(like -, ^^, <<, >>, %, /, ...)
Seems you don't use other things than +, *, &, | and ^, do you?

Re: Annoyance with new integer promotion deprecations

[Dmitry Olshansky via Digitalmars-d]

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 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 expression -cast(int)b of 
type int to

byte

[...]

Honestly, this just makes narrow int types basically useless 
when it comes to any arithmetic at all.




In fact you really shouldn’t do arithmetic on narrow integers, 
especially as loop counters.
It usually results in suboptimal machine code on optimizing 
compilers.


That leaves arrays of bytes and array-wise operations though, 
SIMD by definition can operate on a pack of e.g. byte-sized 
integers.


Bottom line is to use narrow integers only as a way to pack data 
and for SIMD operations in arrays.





T

Re: Annoyance with new integer promotion deprecations

[Luís Marques via Digitalmars-d]

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 it in some 
form in my code, to make dealing with narrow ints saner.  I 
don't know what your .nx type does, but for my purposes I'll 
probably just have a thin wrapper around byte/ubyte/etc. with 
overloaded arithmetic operators that perform the requisite 
casts.


Yeah, it's just a thin wrapper. I implemented just enough to 
cover my use cases but just in case it's useful to you or someone 
else, here goes my implementation...


private struct NX(T)
{
T value;
alias value this;

this(T value)
{
this.value = value;
}

NX!T opUnary(string s)()
{
return NX!T(cast(T) mixin(s ~ "value"));
}

auto opBinary(string op, U)(NX!U rhs)
{
static if(rhs.value.sizeof > value.sizeof)
return mixin("rhs " ~ op ~  " value");
else
return NX!T(cast(T) mixin("value " ~ op ~ " rhs"));
}

NX!T opBinary(string op)(T rhs)
{
return NX!T(cast(T) mixin("value " ~ op ~ " rhs"));
}
}

alias i16 = NX!short;
alias u16 = NX!ushort;
alias i8 = NX!byte;
alias u8 = NX!ubyte;

auto nx(byte v)
{
return i8(v);
}

auto nx(ubyte v)
{
return u8(v);
}

auto nx(short v)
{
return i16(v);
}

auto nx(ushort v)
{
return u16(v);
}

auto nx(int v)
{
return i16(cast(short) v);
}

auto nx(uint v)
{
return u16(cast(ushort) v);
}

Those last two nx() probably won't make sense outside of my 
16-bit target (even though I build the same code for 32 bits too, 
to run the tests on my x86 host).


If you start using something like this in your code please send 
me a link, so I can copy a better implementation :-)

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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 converts/wraps the
> (u)byte/(u)short in my special type. The arithmetic operations are
> infectious, so you only need to apply it to one of the operands (and
> you can preserve it across statements by using "auto" instead of
> "byte"). Because D doesn't have automatic type conversions for the
> function calls, the function signatures still take the standard types,
> and you add .nx where needed in the body.  Because the higher-order
> bits are discarded after each operation, the optimizer easily
> optimizes away the multi-word operations (as least in all of the cases
> I bothered checking...).
[...]
> Unfortunately, I'm not holding my breath for something like this. At
> least D is flexible enough that my .nx solution works! That's saying a
> lot about the language.

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 it in some form in my code, to make dealing
with narrow ints saner.  I don't know what your .nx type does, but for
my purposes I'll probably just have a thin wrapper around
byte/ubyte/etc. with overloaded arithmetic operators that perform the
requisite casts.

And yeah, one thing I really like about D is that it empowers you with
the tools you need to implement types that are (almost) as powerful as
built-in types. While for the most part the built-in stuff is pretty
cool, when it's not up to snuff, in 99% of the cases you can just
replace it with your own solution, and it Just Works(tm).


T

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George 
Orwell

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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 that Walter has reservations about doing
> > this for some reason.
> 
> What you're asking for is data flow analysis. DFA's effectiveness is
> definitely a quality of implementation thing. But if you want to have
> a successful compile depend on DFA, then you've got to define in the
> Specification exactly what DFA is done.
> 
> The next problem is DFA is a complex thing. This is why DFA is done on
> the vastly simplified and canonicalized intermediate code, not the
> ASTs. With dmd's inliner, I made the mistake of doing inlining of the
> ASTs (other compilers do it with the intermediate code). This was a
> major error, and has led to all kinds of peculiar bugs and
> shortcomings. I'm not going to make that mistake again.

What are the chances for inlining to be moved back to the IR? Or is that
not worth contemplating because it's too huge / disruptive of a project?


> Doing DFA for VRP means doing it on the ASTs.
> 
> I know what you're asking for sounds simple enough. But it ain't.

Is it possible to retain VRP information in the IR? Or is that far too
late?


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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, including floats,
> public domain. Someone on IRC was thinking about porting it.
> 
> Maybe we should actually bring that in for the ctfe floats.

Formatting of floats, while apparently rather straightforward on the
surface, is in fact a hairy, monstrously complicated beast of a task,
with all sorts of lovely corner cases and special behaviours (as is
usual for IEEE floats, y'know, bread and butter, nothing surprising).
It's definitely not for the faint of heart to attempt to implement, and
is probably a big reason why Phobos just calls the C function to do the
job for us. :-P

Kudos in advance to whoever has the guts to reimplement it in D so that
we can use it in CTFE.


T

-- 
Political correctness: socially-sanctioned hypocrisy.

Re: Annoyance with new integer promotion deprecations

[Adam D. Ruppe via Digitalmars-d]

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 should actually bring that in for the ctfe floats.

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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");
pragma(msg, "Hello " ~ toStr!x ~ " world");

Note, however, that this doesn't work in CTFE, only at template
expansion time.



There's an easier way that does work in CTFE:

---

import std.conv;

enum x = 100;
pragma(msg, 1.text);
pragma(msg, "Hello " ~ 10.text ~ " world");
pragma(msg, "Hello " ~ x.text ~ " world");

enum y = 2.text;
pragma(msg, y);

//pragma(msg, 3.14159.text); // Ugh, ok, floats don't work though :(

Re: Annoyance with new integer promotion deprecations

[Luís Marques via Digitalmars-d]

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 
discarded. Therefore, I find the cast to be an unnecessary 
addition.


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 type. The arithmetic operations 
are infectious, so you only need to apply it to one of the 
operands (and you can preserve it across statements by using 
"auto" instead of "byte"). Because D doesn't have automatic type 
conversions for the function calls, the function signatures still 
take the standard types, and you add .nx where needed in the 
body. Because the higher-order bits are discarded after each 
operation, the optimizer easily optimizes away the multi-word 
operations (as least in all of the cases I bothered checking...).


Given the impasse between preserving C compatibility and the 
problems that that compatibility brings, I think the ideal 
situation would be to have some kind of mode, in the same way 
that extern(C) is a "mode":


// option 1
pragma(nointpromos): // opt-in
byte c = a + b;

// option 2
pragma(cintpromos): // opt-out of D's new, non-compatible, rules
byte c = cast(byte) (a + b);

Unfortunately, I'm not holding my breath for something like this. 
At least D is flexible enough that my .nx solution works! That's 
saying a lot about the language.

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 flow analysis. DFA's effectiveness is definitely 
a quality of implementation thing. But if you want to have a successful compile 
depend on DFA, then you've got to define in the Specification exactly what DFA 
is done.


The next problem is DFA is a complex thing. This is why DFA is done on the 
vastly simplified and canonicalized intermediate code, not the ASTs. With dmd's 
inliner, I made the mistake of doing inlining of the ASTs (other compilers do it 
with the intermediate code). This was a major error, and has led to all kinds of 
peculiar bugs and shortcomings. I'm not going to make that mistake again.


Doing DFA for VRP means doing it on the ASTs.

I know what you're asking for sounds simple enough. But it ain't.

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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

[H. S. Teoh via Digitalmars-d]

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 thing(tm).

All I can say to that, is to quote Knuth:

People who are more than casually interested in computers should
have at least some idea of what the underlying hardware is like.
Otherwise the programs they write will be pretty weird. -- D.
Knuth


> Fortunately, in D is't absolutely easy to define just that kind of
> types that fullfill all these requirements. Its about 100 LOC.  I call
> them sbyte, sword, sint and slong which are even better names than the
> original ones (because they directly indicate that they are signed and
> match the unsigned ones).  So I never again bother with the completely
> nuts builtin signed types.

Sure, D gives you the flexibility to do that. But if you need high
performance, it will be better to follow the hardware semantics more
closely. It's not D that has completely nuts signed types; it's your
hardware. :-P (Besides the completely nuts casting rules that has
nothing to do with the hardware, that is. That part is a stink we
inherited from C.)


T

-- 
Famous last words: I *think* this will work...

Re: Annoyance with new integer promotion deprecations

[Dominikus Dittes Scherkl via Digitalmars-d]

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 at all?
If two different types are used in an arithmetic operation,
the larger of those two types should be the result type.
And if the result would be truncated in some way, return NAN.

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 thing(tm).


Fortunately, in D is't absolutely easy to define just that kind 
of types

that fullfill all these requirements. Its about 100 LOC.
I call them sbyte, sword, sint and slong which are even better 
names than the original ones (because they directly indicate that 
they are signed and match the unsigned ones).
So I never again bother with the completely nuts builtin signed 
types.

Re: Annoyance with new integer promotion deprecations

[Ola Fosheim Grøstad via Digitalmars-d]

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

[Ola Fosheim Grøstad via Digitalmars-d]

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, though.


D has modular arithmetics across the board so there is no limit 
to what you can stuff into a byte or int.


But doing all calculations as int instead of byte prevents SIMD 
optimizations.

Re: Annoyance with new integer promotion deprecations

[Paolo Invernizzi via Digitalmars-d]

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 implicitly converted to a dchar, but 
not the other way around. Hence, f(byte) is selected as being 
the "most specialized" match.


The overloading rules are fine, but byte should not implicitly 
convert to char/dchar, and char should not implicitly convert 
to byte.


+1

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 :-) and so shorts should 
only be used for data packing purposes.

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 added "because the compiler told me to", but it does make you 
think about what you really want.


D worked that way initially, too. But people strongly complained that it was 
unintuitive and buggy.


> clear in your intention

Except it wasn't. People did not expect truncation and had bugs.

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.


D picked a solution which followed the C rules so that debugged C code will not 
break when transferred to D. This is the correct solution for D. D modified that 
by requiring a cast any time truncation (i.e. losing bits) would happen. 
Although this did technically break C compatibility, there was a compile time 
error generated, so there was no silent breakage.


Changing the semantics would just break a lot of existing, working code in 
undetectable ways, and then introduce another set of unintuitive behaviors that 
a while down the pike will result in more of these threads.


There really isn't much one can do other than learn the integral promotion 
rules. They're only a couple of sentences. We can handle it. (And how 2's 
complement arithmetic works.)

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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 and don't rely on std.conv.to. So it
> doesn't need to be imported, I'm not sure if DMD uses an intrinsic for
> that as well.  I hope it does but can't be certain.

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");
pragma(msg, "Hello " ~ toStr!x ~ " world");

Note, however, that this doesn't work in CTFE, only at template
expansion time.


T

-- 
Programming is not just an act of telling a computer what to do: it is also an 
act of telling other programmers what you wished the computer to do. Both are 
important, and the latter deserves care. -- Andrew Morton

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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
> > Pascal, all those ORD and CHR casts.
> 
> It is a bit ironic hearing this from the guy who made a language where
> you have to cast a byte back to a byte! LOL

+1. Couldn't have said it better! :-D


T

-- 
Food and laptops don't mix.

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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
> > specific example you posted.
> 
> VRP is only for one statement. That is, once you get to the next
> statement it "forgets" what the value range is.
[...]

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.


T

-- 
A bend in the road is not the end of the road unless you fail to make the turn. 
-- Brian White

Re: Annoyance with new integer promotion deprecations

[Timothee Cour via Digitalmars-d]

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  wrote:
> 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* be ugly, it's conflating numerics with partial-characters.
>
> Which, depending on the situation, you should either A. not be doing at all,
> or B. Be really freaking explicit about the fact that "yes, I know I'm
> mixing numerics with partial-characters here and it's for this very good
> reason XYZ." This isn't the age of ASCII. I can see how it could've been a
> pain in ASCII-land, but D doesn't live there.

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer 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 it "forgets" what the value range is.


-Steve

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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* be ugly, it's conflating numerics with partial-characters.

Which, depending on the situation, you should either A. not be doing at 
all, or B. Be really freaking explicit about the fact that "yes, I know 
I'm mixing numerics with partial-characters here and it's for this very 
good reason XYZ." This isn't the age of ASCII. I can see how it could've 
been a pain in ASCII-land, but D doesn't live there.

Re: Annoyance with new integer promotion deprecations

[Jonathan M Davis via Digitalmars-d]

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 complicated
> :-)
> > 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. Pascal works
> this way, and it was one of the things I wound up hating about Pascal,
> all those ORD and CHR casts.
>
> A reasonable case could be made for getting rid of all implicit
> conversions. But those are there for a reason - it makes writing code
> more natural and easy. It allows generic code to work without special
> casing. And the cost of it is sometimes you might make a mistake.

In my experience, relatively little code needs to do arithmetic on
characters. Some definitely does, but far more code does not, and that code
ends up with bugs far too often because of integral types converting to
characters. That's particularly true when stuff like string concatenation
gets involved. I don't know how big a deal it is that characters can
implicitly convert to integral types, and maybe that's okay, but I'm quite
convinced that having integral types implicitly convert to characters was a
mistake.

And as for generic code, my experience is that implicit conversions are an
utter disaster there. It's way too easy to do something like have is(T : U)
in your template constraint and have the code work great with a U but fail
with types that implicitly convert to U. Ideally, all conversions would be
done before the function is called, and if not, the conversion needs to be
forced internally. Otherwise, you either get compilation errors with types
that implicitly convert, or you get subtle bugs.

There are times when implicit conversions can be really nice, but IMHO, they
have no business in generic code.

Also, the fact that (u)bytes and (u)shorts get promoted to (u)ints with
arithmetic is the sort of thing that does not play at all nicely with
generic code. That doesn't necessarily mean that it's a mistake for them to
work that way, but it is a case where you're likely going to be forced to
use explicit casts in generic code just to make those smaller integral types
work when the code would work just fine for other types without the casts.

So, I really don't see arguments with regards to the implicit conversion of
integral types to characters in generic code as holding much water given
what we're doing with the smaller integral types and how the implicit
conversion to character types is something that seems to keep resulting in
folks posting about bugs caused by them in D.Learn - especially when string
appending and concatenation get involved. Pretty much no one wants something
like str ~= 0 to work, but it does, and particularly when you start throwing
in stuff like the ternary operator, folks screw up and end up appending
integers to strings.

- Jonathan M Davis

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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 doesn't have compile-time known values,
such as in the non-reduced code my example snippet was reduced from.



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.

Re: Annoyance with new integer promotion deprecations

[Adam D. Ruppe via Digitalmars-d]

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 a language 
where you have to cast a byte back to a byte! LOL

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 convert to 
char/dchar, and char should not implicitly convert to byte.


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.


A reasonable case could be made for getting rid of all implicit conversions. But 
those are there for a reason - it makes writing code more natural and easy. It 
allows generic code to work without special casing. And the cost of it is 
sometimes you might make a mistake.

Re: Annoyance with new integer promotion deprecations

[Rubn via Digitalmars-d]

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 is a byte can be implicitly converted to a dchar, 
> [...]


This is the root of the problem.  Character types should 
never have been implicitly convertible to/from arithmetic 
integral types in the first place.


+1

Occasionally, it's useful, but in most cases, it just causes 
bugs - especially when you consider stuff like appending to a 
string.


- Jonathan M Davis


I remember a fairly old defect, or maybe it was just a post in 
the Learn forum. Doing "string" ~ 0 would append '\0' to a 
string, because the int was auto-converted to a char. This 
still works today:


import std.stdio;
void main()
{
string msg = "Hello" ~ 0 ~ " D" ~ '\0';
writeln(msg);
writeln(cast(ubyte[])msg);
writeln(cast(ubyte[])"Hello D");
}


Yah that functionality should be deprecated. Idk how realistic 
that is, there might be a lot of code that relies on the implicit 
conversion, but at the very least the conversion should be 
disabled when it is part of a concat with a string. One of the 
reasons for the "~" operator (iirc) was so remove confusion with 
the "+" operator. This goes backwards to that.


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 and don't rely on 
std.conv.to. So it doesn't need to be imported, I'm not sure if 
DMD uses an intrinsic for that as well. I hope it does but can't 
be certain.

Re: Annoyance with new integer promotion deprecations

[Meta via Digitalmars-d]

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, 
> [...]


This is the root of the problem.  Character types should never 
have been implicitly convertible to/from arithmetic integral 
types in the first place.


+1

Occasionally, it's useful, but in most cases, it just causes 
bugs - especially when you consider stuff like appending to a 
string.


- Jonathan M Davis


I remember a fairly old defect, or maybe it was just a post in 
the Learn forum. Doing "string" ~ 0 would append '\0' to a 
string, because the int was auto-converted to a char. This still 
works today:


import std.stdio;
void main()
{
string msg = "Hello" ~ 0 ~ " D" ~ '\0';
writeln(msg);
writeln(cast(ubyte[])msg);
writeln(cast(ubyte[])"Hello D");
}

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer via Digitalmars-d]

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 int, then save it as byte).


But you are saving to an int, not a byte. Anyway, I don't really know 
the specifics of it. I'm not enough of an assembly buff to know the 
differences between what instructions are used or how much they cost.


-Steve

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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 can disagree on... but I'd be perfectly ok if the
> > `a + b` was still typed `byte` just like above... and the data got
> > discarded when assigned to the `int`.
> 
> I think the CPU has to do extra work to throw away that high bit, no?
[...]

Not sure what you mean by "extra work to throw away that high bit".

If a + b is typed as `byte`, then if an underflow happens the upper bits
will just get thrown away, then the result will be sign-extended to int,
losing the original sign. E.g., 0x80 (-128) + 0xFF (-1) = 0x(1)7F
(underflow, the upper (1) gets discarded), sign-extended to 0x007F
(+127).

If a + b was typed as `int` instead, e.g. both a and b were promoted to
int, then the CPU would sign-extend a, sign-extend b, and *then* add the
two together. So 0x80 gets sign-extended to 0xFF80, and 0xFF gets
sign-extended to 0x, and adding the two produces 0xFF7F
(-129). (There's an overflow 1 at the 33rd bit, but that gets
discarded in 32-bit arithmetic.)


T

-- 
May you live all the days of your life. -- Jonathan Swift

Re: Annoyance with new integer promotion deprecations

[Adam D. Ruppe via Digitalmars-d]

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 don't love the idea that:

a = a + 1;

fails, but

++a; a += 1;

works just fine.


indeed. I used to defend that but really the logic goes both 
ways, either way.

Re: Annoyance with new integer promotion deprecations

[Jonathan M Davis via Digitalmars-d]

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 been
> implicitly convertible to/from arithmetic integral types in the first
> place.

+1

Occasionally, it's useful, but in most cases, it just causes bugs -
especially when you consider stuff like appending to a string.

- Jonathan M Davis

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer via Digitalmars-d]

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:
     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 discarded. Therefore, I find 
the cast to be an unnecessary addition.


It could be done that way. 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 added "because the compiler told me to", 
but it does make you think about what you really want.



2) Change it to:
     byte a, b;
     int c = a + b;

This is directly analogous to the float example. Which, I agree, 
reasonable people can disagree on... but I'd be perfectly ok if the `a + 
b` was still typed `byte` just like above... and the data got discarded 
when assigned to the `int`.


I think the CPU has to do extra work to throw away that high bit, no?

But actually, I would be OK with this as well, as long as it was 
consistent across all operations. Right now, it's one way for unary 
operations and another way for binary operations. Just pick a way and 
make it consistent.


I still don't love the idea that:

a = a + 1;

fails, but

++a; a += 1;

works just fine.

But I will grant it is going to be different than the C rules... so it 
would make copy/pasted code a pain. tho copy/pasted code is already a 
pain cuz you gotta insert casts to avoid the errors... but yeah an error 
is less of a hassle than silent change.


So I get why things are the way they are. I just still don't like it :P


Yeah, there's a lot of stuff that's like that ;)

-Steve

Re: Annoyance with new integer promotion deprecations

[Adam D. Ruppe via Digitalmars-d]

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 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 
discarded. Therefore, I find the cast to be an unnecessary 
addition.


2) Change it to:
byte a, b;
int c = a + b;

This is directly analogous to the float example. Which, I agree, 
reasonable people can disagree on... but I'd be perfectly ok if 
the `a + b` was still typed `byte` just like above... and the 
data got discarded when assigned to the `int`.


Just like how you'd write cast(float) 1 / 2, here you can do 
cast(int) a + b to forcibly promote it.




And if we did this consistently across all things, it'd be pretty 
clear you should cast - 127 + 50 here would have discarded info 
so it would stand out a lot faster than just the -a edge case. So 
you'd learn it pretty quickly.



But I will grant it is going to be different than the C rules... 
so it would make copy/pasted code a pain. tho copy/pasted code is 
already a pain cuz you gotta insert casts to avoid the errors... 
but yeah an error is less of a hassle than silent change.


So I get why things are the way they are. I just still don't like 
it :P

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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 subtle changes in behavior.

Exactly; maintaining compatibility with C, the ruiner of all good
things, is a scourge to D that prevents D from adopting saner rules.


> > another example is char -> byte confusion no thanks to C traditions:
> > 
> > int f(dchar ch) { return 1; }
> > int f(byte i) { return 2; }
> > void main() {
> > pragma(msg, f('a'));
> > pragma(msg, f(1));
> > }
> > 
> > Exercise for reader: guess compiler output.
> 
> 'a' and 1 do not match dchar or byte exactly, and require implicit
> conversions. D doesn't have the C++ notion of "better" implicit
> conversions for function arguments, instead it uses the
> "leastAsSpecialized" C++ notion used for template matching, which is
> better.
> 
> The idea is a byte can be implicitly converted to a dchar, [...]

This is the root of the problem.  Character types should never have been
implicitly convertible to/from arithmetic integral types in the first
place.

Again, compatibility with C pessimizes D semantics.  Since D
deliberately defines byte/ubyte as different from char, and char is
defined explicitly to be a UTF-8 code unit, there is really no good
reason to allow implicit conversions between them.  That just undermines
the raison d'être for having separate ubyte and char types, and is a
stink we inherited from C that really ought to be shed already.

It should be C code ported to D that is forced to use casts to explicate
intent, rather than forcing D code to jump through cast hoops just so we
remain "compatible" with C.


T

-- 
Why did the mathematician reinvent the square wheel?  Because he wanted to 
drive smoothly over an inverted catenary road.

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer via Digitalmars-d]

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 promotion makes complete 
sense to me.


Do you feel the same way about

float x = 1/2;

?


Not really. But it is a good counter-argument.

In a way, it's the fact that it's a corner case which makes this more 
sinister. For all bytes *except* byte.min, the behavior is the same 
regardless of whether integer promotion is used or not. So when this bug 
actually occurs, it's going to be in code that "worked for years". And 
in some cases was ported from C and worked there.


But for integer division and assignment to float, it's quite obvious 
that it doesn't work with almost all combinations.


-Steve

Re: Annoyance with new integer promotion deprecations

[Timon Gehr via Digitalmars-d]

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 nor dchar are C types.


another example is char -> byte confusion no thanks to C
traditions:

int f(dchar ch) { return 1; }
int f(byte i) { return 2; }
void main() {
    pragma(msg, f('a'));
    pragma(msg, f(1));
}

Exercise for reader: guess compiler output.


'a' and 1 do not match dchar or byte exactly, and require implicit 
conversions. D doesn't have the C++ notion of "better" implicit 
conversions for function arguments, instead it uses the 
"leastAsSpecialized" C++ notion used for template matching, which is 
better.


The idea is a byte can be implicitly converted to a dchar, but not the 
other way around. Hence, f(byte) is selected as being the "most 
specialized" match.


The overloading rules are fine, but byte should not implicitly convert 
to char/dchar, and char should not implicitly convert to byte.

Re: Annoyance with new integer promotion deprecations

[Adam D. Ruppe via Digitalmars-d]

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.


Do you feel the same way about

float x = 1/2;

?

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer via Digitalmars-d]

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 int, so you can't reassign it to
b.  You can see this today with -transition=intpomote:

Error: cannot implicitly convert expression -cast(int)b of type int to
byte

[...]

Honestly, this just makes narrow int types basically useless when it
comes to any arithmetic at all.


They already are:

b = b + 1; // error.

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.



Sticking to C promotion rules is one of the scourges that continue to
plague D;


C promotion rules came along with the feature of assigning the result 
back to a byte. D got rid of that "convenience", and I think it was a 
good decision. I hardly ever finding myself regretting the compiler 
telling me that I'm about to throw away information.



another example is char -> byte confusion no thanks to C
traditions:

int f(dchar ch) { return 1; }
int f(byte i) { return 2; }
void main() {
pragma(msg, f('a'));
pragma(msg, f(1));
}

Exercise for reader: guess compiler output.


char and byte should not ever mix, IMO. char and dchar should not ever 
mix either. There have been some nasty bugs in phobos due to the fact 
that char auto-promotes to dchar.


-Steve

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer via Digitalmars-d]

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 output the deprecation. Either way, the deprecation is still not 
a full error.


It shouldn't output the deprecation I think: 
https://issues.dlang.org/show_bug.cgi?id=18380


-Steve

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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
traditions:

int f(dchar ch) { return 1; }
int f(byte i) { return 2; }
void main() {
pragma(msg, f('a'));
pragma(msg, f(1));
}

Exercise for reader: guess compiler output.


'a' and 1 do not match dchar or byte exactly, and require implicit conversions. 
D doesn't have the C++ notion of "better" implicit conversions for function 
arguments, instead it uses the "leastAsSpecialized" C++ notion used for template 
matching, which is better.


The idea is a byte can be implicitly converted to a dchar, but not the other way 
around. Hence, f(byte) is selected as being the "most specialized" match.

Re: Annoyance with new integer promotion deprecations

[Adam D. Ruppe via Digitalmars-d]

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 ago... but wrote it in irc and forgot to 
copy lol.


The jist of it was to make int math work kinda like float math. 
Where everything is promoted to the largest type in the 
expression and if truncation happens, so be it.


int a = 1;
int b = 2;
float f = 1/2; // f == 0, we know this and are ok with it

byte a = 127;
byte b = 1;
byte c = a + b; // this should just wrap and assign!


Of course it is slightly different than C. C, the ruiner of all 
good things.

Re: Annoyance with new integer promotion deprecations

[Simen Kjærås via Digitalmars-d]

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 help when the code doesn't have compile-time known 
values, such as in the non-reduced code my example snippet was 
reduced from.


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, though.


--
  Simen

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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 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 doesn't have compile-time known values,
such as in the non-reduced code my example snippet was reduced from.


T

-- 
There are two ways to write error-free programs; only the third one works.

Re: Annoyance with new integer promotion deprecations

[Walter Bright via Digitalmars-d]

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 bug is that VRP should allow this particular case.

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky via Digitalmars-d]

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

[H. S. Teoh via Digitalmars-d]

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 reassign it to
> b.  You can see this today with -transition=intpomote:
> 
> Error: cannot implicitly convert expression -cast(int)b of type int to
> byte
[...]

Honestly, this just makes narrow int types basically useless when it
comes to any arithmetic at all.

Sticking to C promotion rules is one of the scourges that continue to
plague D; another example is char -> byte confusion no thanks to C
traditions:

int f(dchar ch) { return 1; }
int f(byte i) { return 2; }
void main() {
pragma(msg, f('a'));
pragma(msg, f(1));
}

Exercise for reader: guess compiler output.


T

-- 
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer via Digitalmars-d]

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:
/tmp/test.d(7): Deprecation: integral promotion not done for `-s.x[0]`, 
use '-transition=intpromote' switch or `-cast(int)(s.x[0])`
/tmp/test.d(7): Deprecation: integral promotion not done for `-s.x[1]`, 
use '-transition=intpromote' switch or `-cast(int)(s.x[1])`


Why should I need to explicitly cast to int only to reassign it back to
byte?!  This is ridiculous.


Note, it's just a deprecation message, and not an error. So actually, 
your code is compiling just the way it did before the rules (in fact, 
the rules are only implemented if you use the -transition=intpromote 
switch).


In the future, the compiler is going to promote s.x[0] to an int before 
applying the negation. This makes a difference when the byte is byte.min:


byte b = byte.min;
int x = -b;

assert(x == -128) // without -transition=intpromote
assert(x == 128) // with -transition=intpromote (also is the behavior of 
C++)


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 output the deprecation. Either way, the deprecation is still not 
a full error.


In the future, your line initializing t will fail (can't implicitly cast 
int to byte), so you will eventually need a byte cast at least.


-Steve

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer via Digitalmars-d]

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 expression -cast(int)b of type int to byte

-Steve

Re: Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

Even better yet:

byte b;
b = -b; // Deprecation error

WAT


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.

Annoyance with new integer promotion deprecations

[H. S. Teoh via Digitalmars-d]

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 promotion not done for `-s.x[0]`, 
use '-transition=intpromote' switch or `-cast(int)(s.x[0])`
/tmp/test.d(7): Deprecation: integral promotion not done for `-s.x[1]`, 
use '-transition=intpromote' switch or `-cast(int)(s.x[1])`


Why should I need to explicitly cast to int only to reassign it back to
byte?!  This is ridiculous.


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- 
Walter Bright