Jump to page: 1 2 3
Thread overview
opImplicitCast/opImplicitCastFrom
Oct 27, 2008
Hxal
Oct 27, 2008
bearophile
Oct 27, 2008
KennyTM~
Oct 27, 2008
bearophile
Oct 27, 2008
KennyTM~
Oct 27, 2008
bearophile
Oct 27, 2008
Simen Kjaeraas
Oct 27, 2008
Hxal
Oct 27, 2008
bearophile
Oct 27, 2008
Hxal
Oct 27, 2008
Hxal
Oct 27, 2008
Simen Kjaeraas
Oct 27, 2008
bearophile
May 04, 2014
Nordlöw
Oct 28, 2008
Don
Oct 28, 2008
bearophile
Nov 02, 2008
Christopher Wright
Nov 04, 2008
Bruno Medeiros
Nov 04, 2008
Bruno Medeiros
Oct 28, 2008
Jason House
October 27, 2008
So it seems they were supposed to get implemented but it never happened. Were there difficulties in implementing them properly?

Implementing range checked numeric types would be my example of implicit casts' usefulness, but I'm sure a lot of people desire them.

An invocation to:
void foo (intrange!(1,10) x);
currently needs to include a painful cast or constructor call.

October 27, 2008
Hxal:
> Implementing range checked numeric types would be my example of implicit casts' usefulness, but I'm sure a lot of people desire them.<

ObjectPascal programmers use them all the time, they seem to help avoiding some bugs in the program and to better state the meaning of certain variables.

In a modern language it's probably good for ALL integral numeric types to be range checked (when unspecified their range is the whole range their number of bits can represent).

D being a system language, has to allow such checks to be disabled into a module or into the whole program (so some syntax to single-module-disabling may be useful. ObjectPascals uses compiling setting to enable/disable it globally for the whole program, and {$R-} to disable rangle checking locally and {$R+} to enable it locally, locally overriding the compilation setting of the project).

I think that such checks are quite important to avoid bugs. But putting things into the language isn't enough: you have to put them into the head of D programmers and into the D culture. For example in Pascal is very common to use user-defined types to create a stricter (and safer?) type checking; D offers the typedef that allows to do the same (you just have to write 'typedef' for each line of code instead of using a typedef section like typedef: ...). But in my D programs for a long time I haven't used such typedef, and only in the last months I have started to use it more. Sometimes it's a matter of power or syntax (example: D contract programming isn't much powerful, so people may have less incentive to use it. Another example is that if a syntax is too much long, it becomes not convenient to be used, even if its semantic is good, for example certain operations done in functional languages, compared to the same operations done in D) but in the case of typedef I think it's mostly just a matter of being used to use it.

Bye,
bearophile
October 27, 2008
bearophile wrote:
> Hxal:
>> Implementing range checked numeric types would be my example of implicit casts' usefulness, but I'm sure a lot of people desire them.<
> 
> ObjectPascal programmers use them all the time, they seem to help avoiding some bugs in the program and to better state the meaning of certain variables.
> 
> In a modern language it's probably good for ALL integral numeric types to be range checked (when unspecified their range is the whole range their number of bits can represent).
> 

The Bounded!() (originally Positive!()) template suggested by Andrei earlier?

When a programmer cares for integer overflow one can use Bounded!(T.min, T.max).

> D being a system language, has to allow such checks to be disabled into a module or into the whole program (so some syntax to single-module-disabling may be useful. ObjectPascals uses compiling setting to enable/disable it globally for the whole program, and {$R-} to disable rangle checking locally and {$R+} to enable it locally, locally overriding the compilation setting of the project).
> 
> I think that such checks are quite important to avoid bugs. But putting things into the language isn't enough: you have to put them into the head of D programmers and into the D culture. For example in Pascal is very common to use user-defined types to create a stricter (and safer?) type checking; D offers the typedef that allows to do the same (you just have to write 'typedef' for each line of code instead of using a typedef section like typedef: ...). But in my D programs for a long time I haven't used such typedef, and only in the last months I have started to use it more. Sometimes it's a matter of power or syntax (example: D contract programming isn't much powerful, so people may have less incentive to use it. Another example is that if a syntax is too much long, it becomes not convenient to be used, even if its semantic is good, for example certain operations done in functional languages, compared to the same operations done in D) but in the case of typedef I think it
's mostly just a matter of being used to use it.
> 
> Bye,
> bearophile
October 27, 2008
KennyTM~:
> The Bounded!() (originally Positive!()) template suggested by Andrei earlier?

No, I mean something built-in, and generally invisible. See ObjectPascals.


> When a programmer cares for integer overflow one can use Bounded!(T.min, T.max).

Nope. It has to be the other way round: when a programmer doesn't care of avoiding some integer-related bugs he/she/shi can add a "-release" to the compilation arguments. Forcing the programmer to use an ugly and long syntax everywhere in the program isn't a way to avoid that class of bugs in most D programs.

Bye,
bearophile
October 27, 2008
bearophile wrote:
> KennyTM~:
>> The Bounded!() (originally Positive!()) template suggested by Andrei earlier?
> 
> No, I mean something built-in, and generally invisible. See ObjectPascals.
> 

I haven't touched Pascal after Turbo Pascal 7 for DOS, so I thought you're talking about the subrange types in Pascal. I mean something like this:

  var
    x: 1..10;
    y: 'A'..'Z';

Do you mean automatic integer overflow checking (i.e. bounds checking)?

> 
>> When a programmer cares for integer overflow one can use Bounded!(T.min, T.max).
> 
> Nope. It has to be the other way round: when a programmer doesn't care of avoiding some integer-related bugs he/she/shi can add a "-release" to the compilation arguments. Forcing the programmer to use an ugly and long syntax everywhere in the program isn't a way to avoid that class of bugs in most D programs.
> 

I see. This is much more elegant.

> Bye,
> bearophile
October 27, 2008
On Mon, 27 Oct 2008 15:25:32 +0100, bearophile <bearophileHUGS@lycos.com> wrote:

> KennyTM~:
>> The Bounded!() (originally Positive!()) template suggested by Andrei
>> earlier?
>
> No, I mean something built-in, and generally invisible. See ObjectPascals.
>
>
>> When a programmer cares for integer overflow one can use Bounded!(T.min, T.max).
>
> Nope. It has to be the other way round: when a programmer doesn't care of avoiding some integer-related bugs he/she/shi can add a "-release" to the compilation arguments. Forcing the programmer to use an ugly and long syntax everywhere in the program isn't a way to avoid that class of bugs in most D programs.
>
> Bye,
> bearophile

So make all the normal built-in types (uint, int, float, etc) throw exceptions, and give access to lower-level types marked as unsafe.
Basically, rename uint to 'uint_unsafe', and provide 'uint' as a typedef of Bounded!(uint_unsafe.min, uint_unsafe.max).
I feel uint_unsafe is too long a name, but I'm sure something could be worked out (_uint?).

I do believe this would eliminate some bugs, and having programmed quite a lot in ObjectPascal, I agree its nice to have.

-- 
Simen
October 27, 2008
KennyTM~:

> so I thought you're talking about the subrange types in Pascal. I mean something like this:
>    var
>      x: 1..10;
>      y: 'A'..'Z';

Yes, something like that. Plus a syntax like this in D2:
short z;
becomes just a short way to write this:
ushort z: 0 .. 65535;
That is, all integral/char variables become checked range types :-)


> Do you mean automatic integer overflow checking (i.e. bounds checking)?

Yes (But note that here Delphi5 cheats a little).

-----------------

Simen Kjaeraas:

>So make all the normal built-in types (uint, int, float, etc) throw exceptions, and give access to lower-level types marked as unsafe. Basically, rename uint to 'uint_unsafe', and provide 'uint' as a typedef of Bounded!(uint_unsafe.min, uint_unsafe.max). I feel uint_unsafe is too long a name, but I'm sure something could be worked out (_uint?).<

I don't like that.
I think a better solution is to make all char/integral types become range checked by default when not in -release mode, plus add some syntax to disable the range check in a part of the code (or in a module), a bit like the "unsafe" statement of C#, and the {$R-} / {$R+} syntax of Delphi.

What syntax use for D to disable the integral range checks locally? Some possible syntaxes (that can be used for other kind of safeties too, like for the SafeD ideas):

unsafe (IntegerOverflow) { ...code... }
unsafe (IntegerOverflow): ...code...
unsafe (IntegerOverflow) expression;
safe (IntegerOverflow) { ...code... }
safe (IntegerOverflow): ...code...
safe (IntegerOverflow) expression;

Bye,
bearophile
October 27, 2008
Simen Kjaeraas Wrote:
> So make all the normal built-in types (uint, int, float, etc) throw
> exceptions, and give access to lower-level types marked as unsafe.
> Basically, rename uint to 'uint_unsafe', and provide 'uint' as a typedef
> of Bounded!(uint_unsafe.min, uint_unsafe.max).
> I feel uint_unsafe is too long a name, but I'm sure something could be
> worked out (_uint?).

Both overflow-checked and wrap-around integers are useful, the latter kind should not be viewed as inherently unsafe, but rather as a different set of desired semantics. Ada calls these range types and modular types.

Efficient overflow checking would require the use of hardware exceptions, which are currently not convertible to exceptions due to lack of compiler support for non-call exceptions (on Linux at least).

But anyway, the point was to include the implicit cast mechanism to allow
the user to implement such interesting things. No point putting ranged types
into the language if it can be made perfectly doable at library level.
If you put them in the standard lib, people who care about security will
surely use them. (At least if you don't call the type Bounded :P)


October 27, 2008
Hxal:

>No point putting ranged types into the language if it can be made perfectly doable at library level. If you put them in the standard lib, people who care about security will surely use them. (At least if you don't call the type Bounded :P)<

Unfortunately I think such library solution is nearly useless. Programmers are lazy, and lot of them even actively resist changes and ideas that may improve their programs. So I fear that you will see very few programs pasted in this newsgroup that show the usage of that syntax of yours everywhere in the program. And if you suggest the poster to do that change you will receive bites, like when I suggest people to improve the syntax and idioms of some programs shown here.

Even if you put a built-in syntax for ranged types, it's probably quite useless still. If you look at the C language sometimes programmers insert bugs in the code because they forget to initialize vars. D turns the situation over, adding a syntax to not initialize variables, avoiding most of those bugs. The situation with range checkes is similar (not equal, because while the compiler can infer to remove some range checks, some of them have to be left for runtime, this changes the code performance a little, so the situation is more similar to the current bound checks done on of arrays, disabled by -release).

Bye,
bearophile
October 27, 2008
bearophile Wrote:
> Unfortunately I think such library solution is nearly useless. Programmers are lazy, and lot of them even actively resist changes and ideas that may improve their programs.

Well then, that's their problem, isn't it? I mean, there's no point making their programs better against their will. :P

As long as range checked types were part of the standard library and there weren't dozens different implementations from different libraries, then a people would probably use them.

« First   ‹ Prev
1 2 3