digitalmars.D.bugs - [Issue 10999] New: Limited type matching
- d-bugmail puremagic.com (33/33) Sep 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10999
- d-bugmail puremagic.com (17/17) Sep 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10999
- d-bugmail puremagic.com (6/6) Sep 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10999
- d-bugmail puremagic.com (13/17) Sep 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10999
- d-bugmail puremagic.com (25/27) Sep 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10999
- d-bugmail puremagic.com (34/62) Sep 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10999
- d-bugmail puremagic.com (14/14) Sep 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10999
- d-bugmail puremagic.com (16/50) Sep 11 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10999
- d-bugmail puremagic.com (8/9) Sep 11 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10999
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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=10999Reinterpreting 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
http://d.puremagic.com/issues/show_bug.cgi?id=10999 ---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)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.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
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
http://d.puremagic.com/issues/show_bug.cgi?id=10999Please 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
http://d.puremagic.com/issues/show_bug.cgi?id=10999consistency 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