On Tuesday, 28 April 2020 at 18:41:19 UTC, H. S. Teoh wrote:
> Y'know, this makes me wonder if it might be worth having something akin to a compile-time out-contract that asserts certain attributes of the returned type. For example:

That's not a bad idea. You can do that with an ordinary out contract right now and my doc generator includes it too.

auto foo(T)(T t)
        out(ret; isInputRange!(typeof(return))
{
        return t;
}

of course it is run at runtime which means an isInputRange symbol can be generated and such sooo not ideal....... but we could add:

enum ctfe(bool a) = a;

to force that. Maybe even static assert like that, but don't want to add too much syntax lest the docs get ugly again and defeats the point.

maybe.......

```
template Typed(Conds...) {
        bool Typed(R)(R r) {
                static foreach(Cond; Conds)
                        static assert(Cond!R);
                return true;
        }
}

auto foo(T)(T t)
        out(ret; ret.Typed!(isInputRange))
{
        return t;
}
```


That syntax isn't awful, could be fairly legible in docs, does CT checks, optimize to literal `true` in the binary. I know, I know, a bunch of templates but it works today.

On Tuesday, 28 April 2020 at 18:57:37 UTC, welkam wrote:
> On Tuesday, 28 April 2020 at 18:25:28 UTC, Ethan wrote:
>> On Tuesday, 28 April 2020 at 17:06:03 UTC, Adam D. Ruppe wrote:
>>> Type inference itself isn't bad, but the auto in documentation is something I agree isn't great.
>>
>> My hot take after years of explicit typing (remember manual for iterator loops in C++?) and more D metaprogramming than most is that "auto is perfect for things you don't intend the user to store".
>>
>> Since that's all that anti-auto arguments come down to here - the only rational reason you need to know the return type of a function is that you intend on storing it somewhere. And that's kinda pointless with ranges returned by std.algorithm for example.
>>
>> Perhaps there's actually a design win to be had here if we can define nostore or something like that as a return qualifier...
>
> My take on all those that insist on explicit return types is that they have spent long time writing in C and/or C++ and then tried to code in D without learning the language first. Because D doesnt behave the same as their previous languages they have difficulties using the language. Then they proceed to blame external world for their problems.

C++ has auto, it is discouraged to be used frequently unless where it is actually required or of benefit. Otherwise it makes code harder to read and the only benefit then is that it is just easier to write because the programmer is to lazy to put the actual type instead. When you have to dig through templated functions that all just return `auto`, it just encourages the user to use auto as well when they wouldn't have to.

On Tuesday, 28 April 2020 at 16:50:20 UTC, Laust wrote:
> On Tuesday, 28 April 2020 at 10:47:35 UTC, Walter Bright wrote:
>> https://news.ycombinator.com/news
>
> The lukewarm response and the type inference argument make me sad.

Indeed, it's depressing.

On Tuesday, 28 April 2020 at 18:57:23 UTC, H. S. Teoh wrote:
> I *have* found myself wanting to store one of these ranges sometimes -- that's when I pull out typeof() and let the compiler do the heavy lifting for me.  Seriously, it's 2020, why are we still manually typing out type names?!  If it's already obvious from the context, let the compiler fill it in for me, I have better things to do with my time than to retype stuff that the compiler already knows all too well.

Indeed. One might get the idea that those who reject auto and the like must be quite conservative of modernity and/or masochists.

On Tue, Apr 28, 2020 at 10:28:22PM +0000, Jeff C. via Digitalmars-d wrote:
> On Tuesday, 28 April 2020 at 18:57:23 UTC, H. S. Teoh wrote:
> > I *have* found myself wanting to store one of these ranges sometimes -- that's when I pull out typeof() and let the compiler do the heavy lifting for me.  Seriously, it's 2020, why are we still manually typing out type names?!  If it's already obvious from the context, let the compiler fill it in for me, I have better things to do with my time than to retype stuff that the compiler already knows all too well.
> 
> Indeed. One might get the idea that those who reject auto and the like must be quite conservative of modernity and/or masochists.

Don't get me wrong, I despise the philosophy of modernity for the sake of modernity. Of jumping on the bandwagon because it's the bandwagon. (But then again, I also despise the philosophy of conservativeness for the sake of conservativeness, so there's that. :-D)

The real issue here is that we invented machines for the sake of doing repetitive boring stuff that we don't want to do ourselves; now we have a machine that's capable of inferring types for us, why would we want to go back and do the machine's job just for the sake of doing the machine's job?  What can be automated, should be automated.  Life is far too short to be squandered on repetitive tasks that machines can do better, faster, and more reliably than we can.

If anything, I'd say the objections against auto stems more from the lack of a easy UI to have the machine tell us, at a moment's notice, what the inferred type is, than anything to do with type inference itself.  I can sympathize with the frustration that somebody looks at the docs of some function, sees the return type as 'auto', and the description doesn't actually tell you what that type is, what you can do with it, etc..  But if there was a button, say in your IDE or on the docs website or whatever, next to the 'auto', that you can click and it comes back with the name of the type, or better yet, a list of operations / properties you can rely upon to operate on the returned object, then this particular objection will be null and void.

IOW, the objection isn't so much against auto and type inference itself, but a symptom of the lack of an easy, accessible way to query the inferred type (for properties, operations, docs, what-have-you). Type inference is IMO the way of the future. As we build higher and higher abstractions on the machine, we really don't want to be fiddling with the nitty-gritty of actual types every moment.  Let the machine deal with it for us while we focus on the more important things, like, y'know, actually making progress in the problem domain, rather than wasting mental bandwidth micro-managing trifles like what concrete type some function happens to return is.



T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.

On 4/28/2020 9:50 AM, Laust wrote:
> On Tuesday, 28 April 2020 at 10:47:35 UTC, Walter Bright wrote:
>> https://news.ycombinator.com/news
> 
> The lukewarm response and the type inference argument make me sad.

The trouble is that was the first post. The first post usually sets the tone of everything that follows. That's why, when posting links on HackerNews and Reddit, *always* make the first post.

On Wednesday, 29 April 2020 at 04:20:49 UTC, Walter Bright wrote:
> On 4/28/2020 9:50 AM, Laust wrote:
>> On Tuesday, 28 April 2020 at 10:47:35 UTC, Walter Bright wrote:
>>> https://news.ycombinator.com/news
>> 
>> The lukewarm response and the type inference argument make me sad.
>
> The trouble is that was the first post. The first post usually sets the tone of everything that follows. That's why, when posting links on HackerNews and Reddit, *always* make the first post.

Hey there. I'm the person who posted the link on HackerNews (username dgellow), and I directly created a comment with links to your blog series "Das BetterC" to orient the discussion: https://news.ycombinator.com/item?id=23005322.

Not that it matters that much, but as you can see nobody replied to that first comment ¯\_(ツ)_/¯.

On 4/29/2020 1:11 AM, Sam E. wrote:
> Not that it matters that much, but as you can see nobody replied to that first comment ¯\_(ツ)_/¯.

Sorry, I thought it was that other one. Thank you for doing a good first post! It doesn't always work, but the odds are good that it will.

On Tuesday, 28 April 2020 at 19:44:49 UTC, Arine wrote:
> On Tuesday, 28 April 2020 at 18:57:37 UTC, welkam wrote:
>> On Tuesday, 28 April 2020 at 18:25:28 UTC, Ethan wrote:
>>> On Tuesday, 28 April 2020 at 17:06:03 UTC, Adam D. Ruppe wrote:
>>>> Type inference itself isn't bad, but the auto in documentation is something I agree isn't great.
>>>
>>> My hot take after years of explicit typing (remember manual for iterator loops in C++?) and more D metaprogramming than most is that "auto is perfect for things you don't intend the user to store".
>>>
>>> Since that's all that anti-auto arguments come down to here - the only rational reason you need to know the return type of a function is that you intend on storing it somewhere. And that's kinda pointless with ranges returned by std.algorithm for example.
>>>
>>> Perhaps there's actually a design win to be had here if we can define nostore or something like that as a return qualifier...
>>
>> My take on all those that insist on explicit return types is that they have spent long time writing in C and/or C++ and then tried to code in D without learning the language first. Because D doesnt behave the same as their previous languages they have difficulties using the language. Then they proceed to blame external world for their problems.
>
> C++ has auto, it is discouraged to be used frequently unless where it is actually required or of benefit.

https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

> Otherwise it makes code harder to read and the only benefit then is that it is just easier to write because the programmer is to lazy to put the actual type instead.

I don't think actual types are important but what you can do with them is. It's similar to caring what concrete type an OOP instance has. It could be said that instead of auto one should use a concept/trait/typeclass instead, and in fact Bjarne has argued for the inclusion of something like that for C++.


Instead of:

    auto r1 = r0.map!func;

we'd use:

    InputRange!int r1 = r0.map!func;


Where InputRange(T) is a "compile-time interface" and the concrete type can depend on template instantiations.

I think auto right now is overused as a return type though, especially when it actually is a concrete type. Even Haskell encourages explicit typing of module-level functions.