www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10999] New: Limited type matching

reply d-bugmail puremagic.com writes:
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: -------
Sep 09 2013
next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 11 2013
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Sep 11 2013