Steven Schveighoffer: > Or, use a separate type which throws the errors if you wish.
I have recently explained why this is not good enough, or even currently impossible: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=139950 > I don't want > runtime errors thrown in code that I didn't intend to throw. most of the > time, overflows will not occur, so I don't want to go through all my code > and have to throw these decorations up where I know it's safe. The idea is to add two switches to DMD that activate the integral overflows (one for signed and one for signed and unsigned). If you compile your code without those, the runtime tests will not happen. > Besides, D is a systems language, and has no business doing checks > on every integer instruction. This argument doesn't hold, Delphi and Ada too are system languages. > Yes non-relase mode is slower, but we are probably talking > about a very significant slowdown here. A lot of integer math happens in D. Have you done benchmarks or are you refusing something just on a gut feeling? I have done benchmarks of the overflow tests in C# and Delphi and the slowdown we are seeing is not significantly worse than the slowdown caused by array bound tests. And release mode is probably going to be independent from the overflows switches. So you are allowed to compile in non-release mode but without overflow tests. > I think a much more effective fix for the language would be to make slice > length a signed type. Then you simply eliminate 99% of integer overflows > (it's very rare that a signed integer overflows, but not so unlikely that > an unsigned one does). My bug report on this was recently closed by Andrei. I don't mind unsigned fixnums if their bounds are enforced. > At this point, any change to the semantics of the builtin types will be > extremely disruptive. We should focus our efforts elsewhere. This thing is more than named arguments or syntax sugar to unpack tuples :-) Bye, bearophile
