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]

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

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

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.

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

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

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…

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.