d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1977
> 
> 
> schveiguy@yahoo.com changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>          Resolution|INVALID                     |
> 
> 
> 
> 
> ------- Comment #5 from schveiguy@yahoo.com  2008-11-22 08:44 -------
> (In reply to comment #4)
>> It's not ridiculous at all. The compiler cannot tell what values will be
>> possibly passed to f, and the range of byte and short are sufficiently small to
>> make overflow as frequent as it is confusing and undesirable.
> 
> Why is this also flagged (no overflow possible):
> 
> short f(byte i) {
>   byte t = 1;
>   short o = t - i;
>   return o;
> }
> 
>> The community has insisted for a long time to tighten integral operations, and
>> now that it's happening, the tightening is reported as a bug :o).
> 
> But it's pretty inconsistent.  If I add two random ints together, I will get an
> overflow in 25% of cases, why is that not flagged?
> 
> I think the restriction is too tight.  People expect to do math on homogeneous
> types without having to cast the result, as they do with ints.  And I'll say I
> was not one of the people asking for this 'feature'.  I'm not sure where that
> came from.

Personally I think having to insert a cast makes the code more error-prone. The cure is worse than the disease.

Consider also that with the original code, the compiler could install debug-time asserts on any such narrowing conversion. Once you insert a cast, that's impossible, since the language doesn't distinguish between (a) 'I know that is OK' casts, (b) 'I want to pretend that this is a different type' casts, and (c) 'I want you to change this into another type' casts.

Compiler checks should only be inserted for case (a) and (c).

Don wrote:
> d-bugmail@puremagic.com wrote:
>> http://d.puremagic.com/issues/show_bug.cgi?id=1977
>>
>>
>> schveiguy@yahoo.com changed:
>>
>>            What    |Removed                     |Added
>> ---------------------------------------------------------------------------- 
>>
>>              Status|RESOLVED                    |REOPENED
>>          Resolution|INVALID                     |
>>
>>
>>
>>
>> ------- Comment #5 from schveiguy@yahoo.com  2008-11-22 08:44 -------
>> (In reply to comment #4)
>>> It's not ridiculous at all. The compiler cannot tell what values will be
>>> possibly passed to f, and the range of byte and short are sufficiently small to
>>> make overflow as frequent as it is confusing and undesirable.
>>
>> Why is this also flagged (no overflow possible):
>>
>> short f(byte i) {
>>   byte t = 1;
>>   short o = t - i;
>>   return o;
>> }
>>
>>> The community has insisted for a long time to tighten integral operations, and
>>> now that it's happening, the tightening is reported as a bug :o).
>>
>> But it's pretty inconsistent.  If I add two random ints together, I will get an
>> overflow in 25% of cases, why is that not flagged?
>>
>> I think the restriction is too tight.  People expect to do math on homogeneous
>> types without having to cast the result, as they do with ints.  And I'll say I
>> was not one of the people asking for this 'feature'.  I'm not sure where that
>> came from.
> 
> Personally I think having to insert a cast makes the code more error-prone. The cure is worse than the disease.
> 
> Consider also that with the original code, the compiler could install debug-time asserts on any such narrowing conversion. Once you insert a cast, that's impossible, since the language doesn't distinguish between (a) 'I know that is OK' casts, (b) 'I want to pretend that this is a different type' casts, and (c) 'I want you to change this into another type' casts.
> 
> Compiler checks should only be inserted for case (a) and (c).

Could you paste your comment into bugzilla so we have the discussion tracked there? Thanks.

Andrei

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:ggju97$2871$2@digitalmars.com...
<snip>
> Could you paste your comment into bugzilla so we have the discussion tracked there? Thanks.

Has the automatic relaying of newsgroup posts to Bugzilla been discontinued, or does it only work if the email address it's sent from is registered?

It was probably the right thing to do considering the excessive quoting that happens too often.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

On Wed, Nov 26, 2008 at 12:30 PM, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> Has the automatic relaying of newsgroup posts to Bugzilla been discontinued, or does it only work if the email address it's sent from is registered?
>
> It was probably the right thing to do considering the excessive quoting that happens too often.

I got the impression from Brad that he was surprised that it no longer worked, at least when I mentioned it a couple weeks ago.  Maybe some settings just got changed.

http://d.puremagic.com/issues/show_bug.cgi?id=1977


Jason House <jason.james.house@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason.james.house@gmail.com




--- Comment #20 from Jason House <jason.james.house@gmail.com>  2009-08-05 06:11:47 PDT ---
Here's a related issue:

long a;
...
int b = a % 1000;

The sample above gives an error that it can't implicitly convert to int, even though this us exactly the kind of thing implicit narrowing conversions should handle.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1977


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|2.012                       |unspecified
            Summary|Relax warnings for implicit |Relax warnings (D1)/errors
                   |narrowing conversions       |(D2) for implicit narrowing
                   |caused by promotions        |conversions caused by
                   |                            |promotions
         OS/Version|Linux                       |All




--- Comment #21 from Stewart Gordon <smjg@iname.com>  2009-08-08 08:51:28 PDT ---
(In reply to comment #20)
> Here's a related issue:
> 
> long a;
> ...
> int b = a % 1000;
> 
> The sample above gives an error that it can't implicitly convert to int, even though this us exactly the kind of thing implicit narrowing conversions should handle.

That's different, since it isn't due to promotions beyond the lowest common denominator of the operand types.

The best way to deal with this is to spec that the type of a % expression (and similarly &) on integers is the smaller of the operands' types.  There's no loss of significant digits this way, at least if they're both signed or both unsigned.  But if one's signed and the other's unsigned, _then_ what should happen?

If you're worried about breaking existing D1 code, this can still be achieved
by doing this only to the base type and not the promoted type (using the
terminology I introduced at
http://www.digitalmars.com/d/archives/24706.html#N24797
)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1977





--- Comment #22 from Jason House <jason.james.house@gmail.com>  2009-08-08 09:17:31 PDT ---
(In reply to comment #21)

I'm only worrying about D2 where implicit narrowing conversions is part of the spec. ulong%1000 should implicitly allowed when assigning to an integer. Should it be a distinct bugzilla entry?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1977


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com




--- Comment #23 from Andrei Alexandrescu <andrei@metalanguage.com>  2009-08-08 09:39:54 PDT ---
(In reply to comment #22)
> (In reply to comment #21)
> 
> I'm only worrying about D2 where implicit narrowing conversions is part of the spec. ulong%1000 should implicitly allowed when assigning to an integer. Should it be a distinct bugzilla entry?

Range value propagation, which was implemented recently, should take care of this. It's among the simplest examples that should work with range value propagation. The compiler must infer that a % 1000 has range -999 through 999 and therefore should allow it to fit in a short or int.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1977


Ryuichi OHORI <r.97all@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.97all@gmail.com


--- Comment #24 from Ryuichi OHORI <r.97all@gmail.com> 2012-10-12 18:48:51 PDT ---
I still has read not all of the this conversation, but I think my issue is related to this.

trivially incorrect use of op assignment operator is allowed:
    ushort |= int

http://dpaste.dzfl.pl/8b9f5471

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1977


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #25 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-10-12 19:42:37 PDT ---
> trivially incorrect use of op assignment operator is allowed:

Your example is perfectly valid. D uses range value propagation:

http://www.drdobbs.com/tools/value-range-propagation/229300211

It knows the value of both x and y, so it knows that x |= y; will work just fine, because all of the values will fit in the correct types. If the value in y was too large to fit in a ushort, _then_ it should give you an error, but since it fits in a ushort just fine (and is positive, so there's no issues with two's complement or whatnot), the compiler knows that it's fine and allows it without complaint.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------