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
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
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
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
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
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
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
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