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



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



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




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



---


 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







 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




---



 

 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



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







 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







 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