http://d.puremagic.com/issues/show_bug.cgi?id=10999

           Summary: Limited type matching
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: rswhite4@googlemail.com


--- Comment #0 from rswhite4@googlemail.com 2013-09-09 11:08:38 PDT ---
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].

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10999


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #1 from bearophile_hugs@eml.cc 2013-09-10 07:50:26 PDT ---
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).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10999



--- Comment #2 from rswhite4@googlemail.com 2013-09-10 08:15:21 PDT ---
http://forum.dlang.org/thread/uctxceiltlvettsnmojd@forum.dlang.org

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10999


Maxim Fomin <maxim@maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim@maxim-fomin.ru


--- Comment #3 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-09-10 08:24:57 PDT ---
(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).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10999



--- Comment #4 from bearophile_hugs@eml.cc 2013-09-10 09:01:58 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10999



--- Comment #5 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-09-10 09:22:15 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10999


Dicebot <public@dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public@dicebot.lv


--- Comment #6 from Dicebot <public@dicebot.lv> 2013-09-10 09:26:15 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10999



--- Comment #7 from bearophile_hugs@eml.cc 2013-09-11 14:02:28 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10999



--- Comment #8 from bearophile_hugs@eml.cc 2013-09-11 14:06:03 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------