Limited type matching

[dlangBugzillaToGithub]

rswhite4 reported this on 2013-09-09T11:08:38Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=10999

CC List

• Maxim Fomin
• Dicebot (@mihails-strasuns)

Description

Code:

----
import std.stdio;

void foo(short x, short y) { }
void foo(short[2] xy) { }

void main()
{
	foo(1, 2); /// works
	foo([1, 2]); /// works
	
	ushort[2] xy = [1, 2];
	foo(xy); /// fails
	
	ushort x = 1, y = 2;
	foo(x, y); /// works
}
----

If the compiler is able to cast implicit from ushort to short, he should also be able to cast from ushort[2] to short[2].

[dlangBugzillaToGithub]

bearophile_hugs commented on 2013-09-10T07:50:26Z

Implicit casts are generally bad/dangerous, despite they are sometimes handy, so generally we should be careful in introducing even more of them.

I don't like the idea of an implicit cast from ushort[2] to short[2] on the basis of type safety, despite the current design breaks symmetry a little. Sometimes breaking the symmetry is acceptable if it increases safety.

Adding a no-op  cast(short[2])  in the code seems acceptable because this conversion seems uncommon enough (this conversion should call no run-time functions).

[dlangBugzillaToGithub]

rswhite4 commented on 2013-09-10T08:15:21Z

http://forum.dlang.org/thread/uctxceiltlvettsnmojd@forum.dlang.org

[dlangBugzillaToGithub]

maxim commented on 2013-09-10T08:24:57Z

(In reply to comment #1)
>
> I don't like the idea of an implicit cast from ushort[2] to short[2] on the
> basis of type safety, despite the current design breaks symmetry a little.
> Sometimes breaking the symmetry is acceptable if it increases safety.
> 

Reinterpreting short as ushort has nothing to do with type safety - you cannot corrupt anything, you cannot even get wrong value, like in case of dchar<-->long (not all binary values are valid UTF characters).

[dlangBugzillaToGithub]

bearophile_hugs commented on 2013-09-10T09:01:58Z

(In reply to comment #3)

> Reinterpreting short as ushort has nothing to do with type safety - you cannot
> corrupt anything,

"Type safety" is not the same as "memory safety". ushort and short have two different ranges, so Ada language (and functional languages as Haskell, etc) refuse the conversion between them. I don't like the introduction of more implicit type conversions.

The D type system tells apart the two types:


import std.stdio;
void bar(ushort[2]) { "A".writeln; }
void bar(short[2]) { "B".writeln; }
void main() {
    ushort[2] a;
    short[2] b;
    bar(a);
    bar(b);
}


So if you write only the first bar, and you call it with an ushort[2], with your proposal this compiles. If later you add the second bar, now the second bar gets called. This is also what happens with single ushort and short value arguments, but generally it's not a clean design you want to expand to arrays too.

[dlangBugzillaToGithub]

maxim commented on 2013-09-10T09:22:15Z

(In reply to comment #4)
> (In reply to comment #3)
> 
> > Reinterpreting short as ushort has nothing to do with type safety - you cannot
> > corrupt anything,
> 
> "Type safety" is not the same as "memory safety". ushort and short have two
> different ranges, so Ada language (and functional languages as Haskell, etc)
> refuse the conversion between them. I don't like the introduction of more
> implicit type conversions.

Note, that you left important piece of quote. Please elaborate on which kind of type safety is broken by conversion from short to ushort (please with examples of system languages like C/C++). (different ranges is not a problem because it is the same data reinterpreted in differen ways - which is not a surprise in low-level languages)

> The D type system tells apart the two types:
> 
> 
> import std.stdio;
> void bar(ushort[2]) { "A".writeln; }
> void bar(short[2]) { "B".writeln; }
> void main() {
>     ushort[2] a;
>     short[2] b;
>     bar(a);
>     bar(b);
> }
> 
> 
> So if you write only the first bar, and you call it with an ushort[2], with
> your proposal this compiles. If later you add the second bar, now the second
> bar gets called. This is also what happens with single ushort and short value
> arguments, but generally it's not a clean design you want to expand to arrays
> too.

This can't be an argument as similar situation can be created with other conversions in D. In other words, if you consider your example as an argument against implicit conversion, following should also be disallowed:

import std.stdio;

void bar(bool) { "bool".writeln; }
void bar(long) { "long".writeln; }
void main() {
	int a;
    bar(a); // long
    bar(1); // bool
	bar(2); // long
}

import std.stdio;

void bar(int[]) { "int[]".writeln; }
void bar(int[1]) { "int[1]".writeln; }
void main() {
	int[1] a;
	bar(a);    // int[1]
	bar([1]); // int[1]
	bar([]);  // int[]
	bar([1,1]); //int[]
}

and some other conversion stuff.

[dlangBugzillaToGithub]

public (@mihails-strasuns) commented on 2013-09-10T09:26:15Z

Implicit conversion between any signed and unsigned is bad, including short and ushort.

However, it is not likely to go away and thus consistency reasoning must prevail - arrays should convert too. It may be unclean approach but it does not matter, consistency is always much more important.

[dlangBugzillaToGithub]

bearophile_hugs commented on 2013-09-11T14:02:28Z

(In reply to comment #5)

> Please elaborate on which kind of
> type safety is broken by conversion from short to ushort (please with examples
> of system languages like C/C++).

"Type safety" is related to "strong typing". Strong typing means the compiler refuses to use a type (like ushort) where you have specified another type (like short), unless you also have explicitly specified what other types are accepted (this for structural typing, subtyping, etc). And I don't care of C/C++, thankfully D is not one of those two languages.


> (different ranges is not a problem because it
> is the same data reinterpreted in differen ways - which is not a surprise in
> low-level languages)

It's a problem because they are seen as potentially different values, so the semantic of your program could change.


> This can't be an argument as similar situation can be created with other
> conversions in D. In other words, if you consider your example as an argument
> against implicit conversion, following should also be disallowed:
> 
> import std.stdio;
> 
> void bar(bool) { "bool".writeln; }
> void bar(long) { "long".writeln; }
> void main() {
>     int a;
>     bar(a); // long
>     bar(1); // bool
>     bar(2); // long
> }
> 
> import std.stdio;
> 
> void bar(int[]) { "int[]".writeln; }
> void bar(int[1]) { "int[1]".writeln; }
> void main() {
>     int[1] a;
>     bar(a);    // int[1]
>     bar([1]); // int[1]
>     bar([]);  // int[]
>     bar([1,1]); //int[]
> }
> 
> and some other conversion stuff.

There are indeed discussions about changing the semantics of booleans a little in D, to refuse some dangerous implicit conversions. Recently there was a long thread about this in the main D newsgroup.

[dlangBugzillaToGithub]

bearophile_hugs commented on 2013-09-11T14:06:03Z

(In reply to comment #6)

> consistency is always much more important.

In general I don't agree, in D there are several cases where consistency is refused on purpose on the basis of making D safer or less bug-prone.