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.
