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