December 10, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Tuesday, 10 December 2013 at 12:54:58 UTC, bearophile wrote:
> Jonathan M Davis:
>
>> and while [1, 2, 3]s is nice and short, all it does
>> over staticLiteral([1, 2, 3]) is save some typing, and it requires language changes,
>
> [1, 2, 3]s seems nice.
What's with {1, 2, 3}? Should be easy to implement and it's known from C/C++/Java/C#
|
December 10, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | Namespace:
> What's with {1, 2, 3}? Should be easy to implement and it's known from C/C++/Java/C#
In D {} has plenty of meanings already :-)
Bye,
bearophile
|
December 10, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | On Tuesday, 10 December 2013 at 07:29:03 UTC, Kenji Hara wrote:
> This is an intended behavior. An array literal has dynamic array type *by default*.
> But all of literals in D behave as polymorphic.
One of good examples why weakly typed literals suck.
|
December 10, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Tuesday, 10 December 2013 at 14:20:51 UTC, bearophile wrote:
> Namespace:
>
>> What's with {1, 2, 3}? Should be easy to implement and it's known from C/C++/Java/C#
>
> In D {} has plenty of meanings already :-)
>
> Bye,
> bearophile
That is no reason against it. ;)
|
December 10, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Tuesday, 10 December 2013 at 14:20:51 UTC, bearophile wrote:
> Namespace:
>
>> What's with {1, 2, 3}? Should be easy to implement and it's known from C/C++/Java/C#
>
> In D {} has plenty of meanings already :-)
>
> Bye,
> bearophile
I've tried it in the last hour and as I thought, with a few changes it is very easy to implement (it needs currently ~30 lines - however my knowledge of the compiler is very limited, so that it could need some more changes).
But a short test shows, that something like this is possible with my changes:
----
int[] arr0 = [1, 2, 3];
assert(is(typeof(arr0) == int[]));
assert(arr0 == [1, 2, 3]);
int[3] arr1 = {1, 2, 3};
assert(is(typeof(arr1) == int[3]));
assert(arr1 == [1, 2, 3]);
int[] arr2 = {4, 5, 6};
assert(is(typeof(arr2) == int[3]));
assert(arr2 == [4, 5, 6]);
----
I like it. :D
|
December 10, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | Am Tue, 10 Dec 2013 00:26:22 -0800 schrieb Jonathan M Davis <jmdavisProg@gmx.com>: > On Tuesday, December 10, 2013 09:00:22 Namespace wrote: > > I use this implict converting to static arrays very often and if we deprecate it, we really need something to declare static array literals. > > Implicit conversion isn't the problem. It's the fact that there are two possible matches, and it picks one over the other rather than requiring the programmer to indicate which one is correct (e.g. via casting). That's just going to lead to bugs. If there is no conflict, then the implicit conversion is fine. It's just that when there is a conflict that it's a problem. > > We have similar problems with stuff like > > void foo(bool b) {...} > void foo(long l) {...} > > foo(1); //calls the bool overload > > There was a huge thread on this a while back where almost no one other than Walter thought that this behavior was good, and it was clearly causing bugs (Walter argued that the solution was to just add an overload for int rather than fixing the conversion problem). IMHO, there should be no implicit conversion of literals when there's a conflict. It should result in an ambiguity error so that the programmer has the opportunity to indicate the correct overload. > > - Jonathan M Davis In the case above, *if* there was an int overload would you argue for still requiring to use foo(cast(int)1) ? Since that is what would come out of it when cast(int[3])[1,2,3] is required. That would hurt the readability of I/O functions that are specialized for all integral types. EndianStream comes to mind. e.g.: stream.write(cast(int)1); Since cast is a blunt tool, I expect APIs to change away from overloads entirely and use writeInt, writeUbyte etc. instead. -- Marco |
December 10, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | Am Tue, 10 Dec 2013 11:56:40 +0100 schrieb "Kenji Hara" <k.hara.pg@gmail.com>: > On Tuesday, 10 December 2013 at 07:32:08 UTC, Marco Leise wrote: > > [1,2,3] looks like a static array to me. And if overload > > resolution picked the most specialized function it seems > > natural to call the int[3] version. > > My reasoning being that static arrays can be implicitly > > converted to dynamic array, but the reverse is not true. So I > > think it would be better to have [1,2,3] be a static array and > > keep the current behavoir, no?) > > In early D1 age, array literals and string literals had had static array types which corresponding to the literals' element count. However it had caused template code bloat. > > void foo(T)(T arg) { ... } > > foo("aaa"); // instantiate foo!(char[3]) > foo("bbbb"); // instantiate foo!(char[4]) > > foo([1,2]); // instantiate foo!(int[2]) > foo([1,2,3]); // instantiate foo!(int[3]) > > So their types were changed to dynamic array by default. > > Kenji Hara I understand that. The string case probably being the most heavy weight one that prompted the change. Damn, compilers are complicated. -- Marco |
December 11, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Tuesday, 10 December 2013 at 14:20:51 UTC, bearophile wrote:
> Namespace:
>
>> What's with {1, 2, 3}? Should be easy to implement and it's known from C/C++/Java/C#
>
> In D {} has plenty of meanings already :-)
>
> Bye,
> bearophile
You was right, it was terrible and so I tried [1, 2, 3]s as syntax.
It has cost me hours but now this works pretty well:
----
import std.stdio;
void foo(int[3] arr) {
assert(is(typeof(arr) == int[3]));
}
void bar(T)(T arr) {
assert(is(T == int[3]));
}
void main() {
int[] arr0 = [1, 2, 3];
assert(is(typeof(arr0) == int[]));
assert(arr0 == [1, 2, 3]);
int[3] arr1 = [4, 5, 6]s;
assert(is(typeof(arr1) == int[3]));
assert(arr1 == [4, 5, 6]);
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[3]));
assert(arr2 == [7, 8, 9]);
foo([1, 2, 3]);
foo([4, 5, 6]s);
bar([44, 55, 66]s);
auto arr3 = [111, 222, 333];
assert(is(typeof(arr3) == int[]));
auto arr4 = [444, 555, 666]s;
assert(is(typeof(arr4) == int[3]));
}
----
|
December 11, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On Wednesday, 11 December 2013 at 00:37:24 UTC, Namespace wrote: > On Tuesday, 10 December 2013 at 14:20:51 UTC, bearophile wrote: >> Namespace: >> >>> What's with {1, 2, 3}? Should be easy to implement and it's known from C/C++/Java/C# >> >> In D {} has plenty of meanings already :-) >> >> Bye, >> bearophile > > You was right, it was terrible and so I tried [1, 2, 3]s as syntax. > It has cost me hours but now this works pretty well: > > ---- > import std.stdio; > > void foo(int[3] arr) { > assert(is(typeof(arr) == int[3])); > } > > void bar(T)(T arr) { > assert(is(T == int[3])); > } > > void main() { > int[] arr0 = [1, 2, 3]; > assert(is(typeof(arr0) == int[])); > assert(arr0 == [1, 2, 3]); > > int[3] arr1 = [4, 5, 6]s; > assert(is(typeof(arr1) == int[3])); > assert(arr1 == [4, 5, 6]); > > int[] arr2 = [7, 8, 9]s; > assert(is(typeof(arr2) == int[3])); > assert(arr2 == [7, 8, 9]); > > foo([1, 2, 3]); > foo([4, 5, 6]s); > > bar([44, 55, 66]s); > > auto arr3 = [111, 222, 333]; > assert(is(typeof(arr3) == int[])); > > auto arr4 = [444, 555, 666]s; > assert(is(typeof(arr4) == int[3])); > } > ---- Would be nice if someone could review it, maybe it's worth to add: Branch: https://github.com/Dgame/dmd/tree/static_array_literals Commit: https://github.com/Dgame/dmd/commit/6296057d919d50b407d4533bab5d2a21fba6230c |
December 11, 2013 Re: Type inference and overloaded functions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On 12/10/2013 04:37 PM, Namespace wrote: > int[] arr2 = [7, 8, 9]s; > assert(is(typeof(arr2) == int[3])); That looks very confusing. The left-hand side looks like a slice, which I can append elements to but its type is a static array? Ali |
Copyright © 1999-2021 by the D Language Foundation