On Fri, May 11, 2018 at 04:57:05PM +0000, Mark via Digitalmars-d wrote:
> On Wednesday, 9 May 2018 at 15:06:55 UTC, Jonathan M Davis wrote:
> > Ultimately, the key is that the user of the function needs to be able to know how to use the return type. In some cases, that means returning a specific type, whereas in others, it means using auto and being clear in the documentation about what kind of API the return type has. As long as the API is clear, then auto can be fantastic, but if the documentation is poorly written (or non-existant), then it can be a serious problem.
> > 
> > - Jonathan M Davis
> 
> He also needs to know what requirements the parameters of the function should satisfy. We have template constraints for that, even though that could also have been "implemented" through documentation.

This makes me wonder if it might be useful to have return-type constraints.  A kind of static out-contract?  Something that's part of the function declaration, that ensures that the return type satisfies certain properties.

	// Hypothetical syntax
	auto myfunc(R)(R r)
	if (isInputRange!R &&
		isOutputRange!return)
	{
		... // implementation here
	}

The `isOutputRange!return` (this is just tentative syntax, you guys can probably think of better ways of writing this) statically enforces that the return type must satisfy `isOutputRange`, and, being part of the function signature, documents to the user what to expect of it.

Could be valuable.

Of course, we could repurpose existing out contracts for this, e.g.:

	auto myfunc(R)(R r)
	if (isInputRange!R)
	out(r) { static assert(isOutputRange!(typeof(r))); }
	do
	{
	}

A little more verbose, and has issues with the semantics of -release, etc., but at least it gets the point across.


T

-- 
In order to understand recursion you must first understand recursion.

On Friday, 11 May 2018 at 18:44:25 UTC, H. S. Teoh wrote:
> On Fri, May 11, 2018 at 04:57:05PM +0000, Mark via Digitalmars-d wrote:
>> [...]
>
> This makes me wonder if it might be useful to have return-type constraints.  A kind of static out-contract?  Something that's part of the function declaration, that ensures that the return type satisfies certain properties.
>
> [...]

Coincidentally, over in Rust...

https://blog.rust-lang.org/2018/05/10/Rust-1.26.html

On Fri, May 11, 2018 at 06:56:13PM +0000, Chris M. via Digitalmars-d wrote:
> On Friday, 11 May 2018 at 18:44:25 UTC, H. S. Teoh wrote:
> > On Fri, May 11, 2018 at 04:57:05PM +0000, Mark via Digitalmars-d wrote:
> > > [...]
> > 
> > This makes me wonder if it might be useful to have return-type constraints.  A kind of static out-contract?  Something that's part of the function declaration, that ensures that the return type satisfies certain properties.
> > 
> > [...]
> 
> Coincidentally, over in Rust...
> 
> https://blog.rust-lang.org/2018/05/10/Rust-1.26.html

Great minds think alike. :-D

(Or fools seldom differ?)


T

-- 
The problem with the world is that everybody else is stupid.

On Friday, 11 May 2018 at 18:44:25 UTC, H. S. Teoh wrote:
> On Fri, May 11, 2018 at 04:57:05PM +0000, Mark via Digitalmars-d wrote:
>> On Wednesday, 9 May 2018 at 15:06:55 UTC, Jonathan M Davis wrote:
>> > Ultimately, the key is that the user of the function needs to be able to know how to use the return type. In some cases, that means returning a specific type, whereas in others, it means using auto and being clear in the documentation about what kind of API the return type has. As long as the API is clear, then auto can be fantastic, but if the documentation is poorly written (or non-existant), then it can be a serious problem.
>> > 
>> > - Jonathan M Davis
>> 
>> He also needs to know what requirements the parameters of the function should satisfy. We have template constraints for that, even though that could also have been "implemented" through documentation.
>
> This makes me wonder if it might be useful to have return-type constraints.  A kind of static out-contract?  Something that's part of the function declaration, that ensures that the return type satisfies certain properties.
>
> 	// Hypothetical syntax
> 	auto myfunc(R)(R r)
> 	if (isInputRange!R &&
> 		isOutputRange!return)
> 	{
> 		... // implementation here
> 	}
>
> The `isOutputRange!return` (this is just tentative syntax, you guys can probably think of better ways of writing this) statically enforces that the return type must satisfy `isOutputRange`, and, being part of the function signature, documents to the user what to expect of it.
-
> T

This method won't work for non-template functions (since template constraints can be used only in, well, templates). Granted, non-template functions with auto return type are pretty rare, but we probably don't want to impose an unnecessary restriction.

On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
> So I'm curious, what's the consensus on auto?

In the example below, what would I use, besides auto?

------------------------
module test;

void main ()
{
    import std.stdio : writeln;
    auto result = newKing("King Joffrey");
    writeln(result.getName);
}

auto newKing(string name)
{
    class King
    {
        private string _name;
        public string getName() { return this._name ~ " : the one true king!"; }
        this() { this._name = name; }
    }

    return new King;
}

------------------------------

On Wednesday, 16 May 2018 at 10:52:42 UTC, KingJoffrey wrote:
> On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
>> So I'm curious, what's the consensus on auto?
>
> In the example below, what would I use, besides auto?

auto is required for Voldemort types, so you would change it to not be a Voldemort type.

On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote:
> I'll freely admit I haven't put a ton of thought into this post (never a good start), however I'm genuinely curious what people's feeling are with regards to the auto keyword.

I prefer types spelled as it helps to understand the code. In javascript I have to look around to figure out types of variables and then I can understand the code. In C# I saw surprising abuse like `var id = 0L;` - to think someone would go to such length only to insist on type inference.
In part this can be due to unreasonably difficult to spell types like ptrdiff_t, so I try to design my code in a way that it's easy to spell types.

On Thursday, 17 May 2018 at 11:38:13 UTC, Kagamin wrote:
>
> I prefer types spelled as it helps to understand the code. In javascript I have to look around to figure out types of variables and then I can understand the code. In C# I saw surprising abuse like `var id = 0L;` - to think someone would go to such length only to insist on type inference.
> In part this can be due to unreasonably difficult to spell types like ptrdiff_t, so I try to design my code in a way that it's easy to spell types.

I was working with Java 8 this week, and God did I miss `auto`. And now Java will get `var`[1], t'was about time, indeed! Java 8 introduced lambdas and functional style features. For lambdas and streams the compiler aleady performs automatic type inference (as it does for generics, btw). So the next logical step is local type inference with `var`. I think that a functional apporach (stream().filter().map()...) leads almost automatically to `auto` (pardon the pun). Else programming becomes very cumbersome, because you have to keep track of the types all the way down the chain. That's time better spent somewhere else.

In a way Java has slowly been moving in that direction anyway, cf. this answer [2] that reminded me of D's `auto` return type.


[1] http://segasolutionsinc.com/2018/03/30/var-in-java10/
[2] https://stackoverflow.com/questions/1348199/what-is-the-difference-between-the-hashmap-and-map-objects-in-java

On Friday, 18 May 2018 at 10:09:20 UTC, Chris wrote:
> In a way Java has slowly been moving in that direction anyway, cf. this answer [2] that reminded me of D's `auto` return type.
> [2] https://stackoverflow.com/questions/1348199/what-is-the-difference-between-the-hashmap-and-map-objects-in-java

Except the return type that you wrote in that case tells you almost everything you can do with that value. If you specify the return type of a function as `auto`, it tells you nothing. The Java equivalent would be to return Object.

On Friday, 18 May 2018 at 16:25:52 UTC, Neia Neutuladh wrote:
> On Friday, 18 May 2018 at 10:09:20 UTC, Chris wrote:
>> In a way Java has slowly been moving in that direction anyway, cf. this answer [2] that reminded me of D's `auto` return type.
>> [2] https://stackoverflow.com/questions/1348199/what-is-the-difference-between-the-hashmap-and-map-objects-in-java
>
> Except the return type that you wrote in that case tells you almost everything you can do with that value. If you specify the return type of a function as `auto`, it tells you nothing. The Java equivalent would be to return Object.

My point was about implementing an interface you can rely on, regardless of what auto returns, eg:

auto name = user.name;

user could be anything, but it still has the field / property 'name'.