OT (partially): about promotion of integers

[H. S. Teoh]

On Wed, Dec 12, 2012 at 02:15:24AM +0100, bearophile wrote:
> H. S. Teoh:
> 
> >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.
> 
> The idea was about two switches, one for signed integrals, and the
> other for both signed and unsigned. But from other posts I guess
> Walter doesn't think this is a viable possibility.

Two switches is even worse than one. The problem is that existing code
assumes certain kind of behaviours from int, uint, etc.. Such code may
exist in common libraries imported by your code (directly or indrectly).
Now you compile your code with a switch (or two switches) that modifies
the behaviour of int, and things start to break. Even worse, if you only
use the switches on certain critical source files, then you may end up
with incompatible behaviour of the same library code in the same
executable (e.g. a template got instantiated once with the switches
enabled, once without). It leads to all kinds of inconsistencies and
subtle breakages that totally outweigh whatever benefits it may have
had.


> So the solutions I see now are stop using D for some kind of more
> important programs, or using some kind of safeInt, and then work with
> the compiler writers to allow user-defined structs to be usable as
> naturally as possible as ints (and possibly efficiently).

It's not too late to add a new native type (or types) to the language
that support this kind of checking. I see that as the best solution to
this issue. Don't mess with the existing types, because too much already
depends on it. Add a new type that has the desired behaviour.

But you may have a hard time convincing Walter to put it in, though.


> Regarding safeInt I think today there is no way to write it
> efficiently in D, because the overflow flags are not accessible from
> D, and if you use inlined asm, you lose inlining in DMD. This is
> just one of the problems. The other problems are syntax
> incompatibilities of user-defined structs compared to built-in ints.
> Other problems are the probable lack of high-level optimizations
> done on such user defined type.
[...]

These are implementation issues that we can work on improving. For one
thing, I'd love to see D get closer to the point where the distinction
between built-in types and user-defined types is gone. We may never
actually reach that point, but the closer we get, the better. This will
let us solve a lot of things, like drop-in replacements for AA's, etc.,
that are a bit ugly to do today.

One thing I've always thought about is a way for user-types to specify
sub-expression optimizations that the compiler can apply. Basically, if
I implement, say, a Matrix class, then I should be able to tell the
compiler that certain Matrix expressions, say A*B+A*C, can be factored
into A*(B+C), and have the optimizer automatically do this for me based
on what is defined in the type. Or specify that write("a");writeln("b");
can be replaced by writeln("ab");. But I haven't come up with a good
generic framework for actually making this implementable yet.


T

-- 
I don't trust computers, I've spent too long programming to think that
they can get anything right. -- James Miller