www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Auto returntype

reply Alex <AJ gmail.com> writes:
One thing D does not have in it's type system is the ability to 
infer the return type from the usage:

O[] foo() { O[] x; return x; }
byte[] q = foo();

The idea is that O is determined to be byte. The compiler looks 
at the assignment and realizes that we want foo to return a byte 
array and that O then must be a byte.

This avoids having to specify the type in foo
e.g., we could have

auto foo(O)() { O[] x; return x; }
auto q = foo!byte();


I think the first case makes more sense. They are effectively the 
same, at least in initialization code when the lvalue's type can 
be determine.

What it mainly does is avoid having to specify the return type as 
a parameter and looks more natural.
If there were never an issues this would be idea because it can 
save a parameter in some cases and make for cleaner code.


If no one see's any issues with this then it would be a simple 
rewrite rule.

Can anyone see any failures of such code?

[Can, the return type much be determined from the lvalue]
May 19 2019
next sibling parent reply Para <email address.tld> writes:
On Sunday, 19 May 2019 at 22:57:50 UTC, Alex wrote:

 One thing D does not have in it's type system is the ability to 
 infer the return type from the usage:

 O[] foo() { O[] x; return x; }
 byte[] q = foo();

 The idea is that O is determined to be byte. The compiler looks 
 at the assignment and realizes that we want foo to return a 
 byte array and that O then must be a byte.

 This avoids having to specify the type in foo
 e.g., we could have

 auto foo(O)() { O[] x; return x; }
 auto q = foo!byte();


Unless I have very poor reading comprehension, which I might, I 
believe this is already a feature: 
https://dlang.org/spec/function.html#auto-functions
May 19 2019
parent reply sarn <sarn theartofmachinery.com> writes:
On Sunday, 19 May 2019 at 23:10:08 UTC, Para wrote:

 Unless I have very poor reading comprehension, which I might, I 
 believe this is already a feature: 
 https://dlang.org/spec/function.html#auto-functions


The type of an auto function is inferred from the return 
argument, but I think Alex wants more sophisticated inference 
based on usage.  Maybe something like Hindley-Milner, as used in 
Haskell: 
http://www.codecommit.com/blog/scala/what-is-hindley-milner-and-why-is-it-cool

D's templates could theoretically support more inference, but 
that would need
1) Someone interested enough to implement it
2) Someone who can convince Walter that it won't make D's 
template system too complicated
May 19 2019
parent reply Alex <AJ gmail.com> writes:
On Monday, 20 May 2019 at 00:31:48 UTC, sarn wrote:

 On Sunday, 19 May 2019 at 23:10:08 UTC, Para wrote:

 Unless I have very poor reading comprehension, which I might, 
 I believe this is already a feature: 
 https://dlang.org/spec/function.html#auto-functions


 The type of an auto function is inferred from the return 
 argument, but I think Alex wants more sophisticated inference 
 based on usage.  Maybe something like Hindley-Milner, as used 
 in Haskell: 
 http://www.codecommit.com/blog/scala/what-is-hindley-milner-and-why-is-it-cool


Yes, but it's much easier than that. No reason to infer anything. 
The type is the lvalue's type. but it requires one to determine 
that the lvalue has a type. In fact, maybe it could be a more 
general thing where one could simply get the lvalue(see below).


 D's templates could theoretically support more inference, but 
 that would need
 1) Someone interested enough to implement it
 2) Someone who can convince Walter that it won't make D's 
 template system too complicated


First it should be proved to be a sound idea, else it is 
pointless to do 1 and 2.

----


One could in general get the assignment type and use that in code 
to perform polymorphic behavior:


T foo()
{
    writeln(T.stringof);
    T x;
    return x;
}


int x = foo();
float x = foo();

prints

int
float


It requires that the lvalue's type be known and parsed before the 
template call... not a hard problem but might not be implemented 
in D as such.
May 19 2019
parent Alex <sascha.orlov gmail.com> writes:
On Monday, 20 May 2019 at 02:32:47 UTC, Alex wrote:

 On Monday, 20 May 2019 at 00:31:48 UTC, sarn wrote:

 On Sunday, 19 May 2019 at 23:10:08 UTC, Para wrote:

 Unless I have very poor reading comprehension, which I might, 
 I believe this is already a feature: 
 https://dlang.org/spec/function.html#auto-functions


 The type of an auto function is inferred from the return 
 argument, but I think Alex wants more sophisticated inference 
 based on usage.  Maybe something like Hindley-Milner, as used 
 in Haskell: 
 http://www.codecommit.com/blog/scala/what-is-hindley-milner-and-why-is-it-cool


 Yes, but it's much easier than that. No reason to infer 
 anything. The type is the lvalue's type. but it requires one to 
 determine that the lvalue has a type. In fact, maybe it could 
 be a more general thing where one could simply get the 
 lvalue(see below).


 D's templates could theoretically support more inference, but 
 that would need
 1) Someone interested enough to implement it
 2) Someone who can convince Walter that it won't make D's 
 template system too complicated


 First it should be proved to be a sound idea, else it is 
 pointless to do 1 and 2.

 ----


 One could in general get the assignment type and use that in 
 code to perform polymorphic behavior:


 T foo()
 {
    writeln(T.stringof);
    T x;
    return x;
 }


 int x = foo();
 float x = foo();

 prints

 int
 float


 It requires that the lvalue's type be known and parsed before 
 the template call... not a hard problem but might not be 
 implemented in D as such.


You propose just a new lowering rule for templates, no? If so, 
you just have to list all existent relevant rules (at least here, 
in the forum) and if there aren't any contradictions to the new 
one, chances are, your proposition will be accepted... maybe... :)
The other end of the rod is, that it used to be auto var = 
foo!(type, if any); and not the other way round. This is a 
question of habituation, I think. I mean, the possibility to 
write it in the used way does not vanish, just because a new 
lowering rule is introduced.
And last but not least, readability is subjective. With your 
proposition, you would hide templates as such. Not sure, if this 
is wanted...
May 20 2019
prev sibling next sibling parent reply Andrea Fontana <nospam example.org> writes:
On Sunday, 19 May 2019 at 22:57:50 UTC, Alex wrote:

 One thing D does not have in it's type system is the ability to 
 infer the return type from the usage:

 O[] foo() { O[] x; return x; }
 byte[] q = foo();

 The idea is that O is determined to be byte. The compiler looks 
 at the assignment and realizes that we want foo to return a 
 byte array and that O then must be a byte.


I've just tried a few time. No way to get this idea implemented, 
I'm sorry :)
https://forum.dlang.org/thread/ufhibwmouxpivjylqdgm forum.dlang.org
May 20 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 20 May 2019 at 08:31:14 UTC, Andrea Fontana wrote:

 I've just tried a few time. No way to get this idea 
 implemented, I'm sorry :)
 https://forum.dlang.org/thread/ufhibwmouxpivjylqdgm forum.dlang.org


You also have this thread: "Idea: Reverse Type Inference"

https://forum.dlang.org/thread/qmmjiofwmzqzdsgmvrai forum.dlang.org?page=1

Probably many more…
May 20 2019
prev sibling parent Dennis <dkorpel gmail.com> writes:
On Sunday, 19 May 2019 at 22:57:50 UTC, Alex wrote:

 Can anyone see any failures of such code?


If you first declare a function:
T func(T a);

And then import a module that defines a public struct T, suddenly 
you have a regular function instead of a template function. With 
that syntax, you can't distinguish template functions from 
regular functions from the grammar alone anymore.
May 20 2019