OT (partially): about promotion of integers

[foobar]

On Wednesday, 12 December 2012 at 00:43:39 UTC, H. S. Teoh wrote:
> On Wed, Dec 12, 2012 at 01:26:08AM +0100, foobar wrote:
>> On Wednesday, 12 December 2012 at 00:06:53 UTC, bearophile 
>> wrote:
>> >foobar:
>> >
>> >>I would enforce overflow and underflow checking semantics.<
>> >
>> >Plus one or two switches to disable such checking, if/when 
>> >someone
>> >wants it, to regain the C performance. (Plus some syntax way 
>> >to
>> >disable/enable such checking in a small piece of code).
>> >
>> >Maybe someday Walter will change his mind about this topic :-)
>
> I don't agree that compiler switches should change language 
> semantics.
> Just because you specify a certain compiler switch, it can cause
> unrelated breakage in some obscure library somewhere, that 
> assumes
> modular arithmetic with C/C++ semantics. And this breakage will 
> in all
> likelihood go *unnoticed* until your software is running on the
> customer's site and then it crashes horribly. And good luck 
> debugging
> that, because the breakage can be very subtle, plus it's *not* 
> in your
> own code, but in some obscure library code that you're not 
> familiar
> with.
>
> I think a much better approach is to introduce a new type (or 
> new types)
> that *does* have the requisite bounds checking and static 
> analysis.
> That's what a type system is for.
>
>
> [...]
>> Yeah, of course, that's why I said the C# semantics are _way_
>> better. (That's a self quote)
>> 
>> btw, here's the link for SML which does not use tagged ints -
>> http://www.standardml.org/Basis/word.html#Word8:STR:SPEC
>> 
>> "Instances of the signature WORD provide a type of unsigned 
>> integer
>> with modular arithmetic and logical operations and conversion
>> operations. They are also meant to give efficient access to the
>> primitive machine word types of the underlying hardware, and 
>> support
>> bit-level operations on integers. They are not meant to be a
>> ``larger'' int. "
>
> It's kinda too late for D to rename int to word, say, but it's 
> not too
> late to introduce a new checked int type, say 'number' or 
> something like
> that (you can probably think of a better name).
>
> In fact, Andrei describes a CheckedInt type that uses operator
> overloading, etc., to implement an in-library solution to 
> bounds checks.
> You can probably expand that into a workable lightweight int
> replacement. By wrapping an int in a struct with custom 
> operators, you
> can pretty much have an int-sized type (with value semantics, 
> just like
> "native" ints, no less!) that does what you want, instead of 
> the usual
> C/C++ int semantics.
>
>
> T

I didn't say D should change the implementation of integers, in 
fact I said the exact opposite - that it's probably to late to 
change the semantics for D. Had D was designed from scratch than 
yes, I would have advocated for a different design, either the C# 
one or as you suggest go even further and have two distinct types 
(as in SML) which is even better. But by no means am I to suggest 
to change D semantics _now_. Sadly, it's likely to late and we 
can only try to paper it on top with additional library types. 
This isn't a perfect solutions since the compiler has builtin 
knowledge about int and does optimizations that will be lost with 
a library type.