On Tuesday, 28 April 2020 at 14:16:59 UTC, Ali Çehreli wrote:
> On 4/28/20 4:06 AM, Ethan wrote:
>> On Tuesday, 28 April 2020 at 10:47:35 UTC, Walter Bright wrote:
>>> https://news.ycombinator.com/news
>> 
>> I'm certain this is said every time you link to hackernews, but that front page link very quickly becomes stale for your intended purpose of illustrating what article is on top.
>> 
>> https://news.ycombinator.com/item?id=23005297
>
> I'm with Ethan on this one and I have posted a specific link in the past as well.
>
> If what we fear is true (and I doubt it because the site seems to attract smart people), then Hacker News is wrong. Internet works with specific links.
>
> Ali

The current HN rules state: "Don't solicit upvotes, comments, or submissions." I don't know if they've changed the rules over time, but it used to mean that if you posted something on a forum so that everyone would vote for it, the post would be deleted or pushed off the front page.

On Tuesday, 28 April 2020 at 14:30:57 UTC, bachmeier wrote:
> The current HN rules state: "Don't solicit upvotes, comments, or submissions." I don't know if they've changed the rules over time, but it used to mean that if you posted something on a forum so that everyone would vote for it, the post would be deleted or pushed off the front page.

So I guess Walter explicitly calling out voting as a reason he doesn't link the article itself qualifies as soliciting votes? It certainly makes it hard to argue that isn't the case.

I didn't even know voting was an intended thing until I mentioned it on IRC and in here. And my response there is still my stance:

14:28 <GooberMan> irrelevant if it drops off the front page in an hour's time anyway
14:28 <GooberMan> take a screenshot if you have to, linking to the front page is pointless for timespans of longer than a few hours

(Article is at #4 currently, seen it go down past #10 since this thread started)

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.

On Tuesday, 28 April 2020 at 16:50:20 UTC, Laust wrote:
> The lukewarm response and the type inference argument make me sad.

Type inference itself isn't bad, but the auto in documentation is something I agree isn't great.

So I recently wrote this thing:
http://dpldocs.info/experimental-docs/arsd.mvd.mvd.html


It originally said:

auto mvd(alias fn).......

and then I changed it to:

CommonReturnOfOverloads!fn mvd(alias fn).......


just because I wanted the return type to be a little bit clearer. And you can use the helper thing externally too which is sometimes useful.

But it could just as well have said /// Returns: common type of overloads of the passed function

sooooo idk, just I kinda see the point and have avoided `auto` for exactly that reason myself sometimes.

On 4/28/20 1:06 PM, Adam D. Ruppe wrote:
> On Tuesday, 28 April 2020 at 16:50:20 UTC, Laust wrote:
>> The lukewarm response and the type inference argument make me sad.
> 
> Type inference itself isn't bad, but the auto in documentation is something I agree isn't great.
> 
> So I recently wrote this thing:
> http://dpldocs.info/experimental-docs/arsd.mvd.mvd.html
> 
> 
> It originally said:
> 
> auto mvd(alias fn).......
> 
> and then I changed it to:
> 
> CommonReturnOfOverloads!fn mvd(alias fn).......
> 
> 
> just because I wanted the return type to be a little bit clearer. And you can use the helper thing externally too which is sometimes useful.
> 
> But it could just as well have said /// Returns: common type of overloads of the passed function
> 
> sooooo idk, just I kinda see the point and have avoided `auto` for exactly that reason myself sometimes.

Yeah, the whole thread is ignoring that there's actual documentation for those functions which says what it returns, and IMO it's more descriptive than some long machine-usable multi-page type generation thing that nobody will comprehend.

There are certainly cases where auto is overused. I also think, if there is a non-template return type, auto could be changed to returning that type in the docs.

Like I had to make this change, but it would have been nice if the compiler just did it for me: https://github.com/dlang/phobos/pull/7451

-Steve

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

On Tue, Apr 28, 2020 at 02:07:07PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 4/28/20 1:06 PM, Adam D. Ruppe wrote:
> > On Tuesday, 28 April 2020 at 16:50:20 UTC, Laust wrote:
> > > The lukewarm response and the type inference argument make me sad.
> > 
> > Type inference itself isn't bad, but the auto in documentation is something I agree isn't great.
[...]
> Yeah, the whole thread is ignoring that there's actual documentation for those functions which says what it returns, and IMO it's more descriptive than some long machine-usable multi-page type generation thing that nobody will comprehend.
> 
> There are certainly cases where auto is overused. I also think, if there is a non-template return type, auto could be changed to returning that type in the docs.
[...]

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:

	// (N.B.: hypothetical syntax)
	auto myComplexRangeFunc(R, Args...)(R range, Args args)
		if (isInputRange!R && is(ElementType!R : SomeType))
		out (S result; isInputRange!S && is(ElementType!S : SomeOtherType))
	{
		return ... /* some complicated Voldemort type */
	}

The point is, sometimes you don't *want* user code to be dependent on the type you return, but you *do* want some sort of assurance, beyond textual description in the docs, of what operations you can perform on the return type.  An out-contract (or equivalent) seems like a good place to put such assertions.


T

-- 
"Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra

InputRange!(ElementType: T) adder(T)(T[] data...);

Name: signatures, traits or protocols

I haven't got around to writing up an actual article proposing it but here is a write up:

https://gist.github.com/rikkimax/826e1c4deb531e8dd993815bf914acea#signatures

On Tue, Apr 28, 2020 at 06:25:28PM +0000, Ethan via Digitalmars-d 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++?)

Oy, that brings back the nightmares. :-/  Explicitly spelling out iterators in C++ was one of the least pleasant moments that I wish I can forget forever. What ought to have been a 1-line "foreach (item; collection)" had to be spread over a multi-line monstrosity sprouting ::'s like maggots.  And then the traits templates that were thrown in for good measure...  DRY was assaulted, maimed, and slaughtered, then dumped on the wayside to rot.  Ick.


> and more D metaprogramming than most is that "auto is perfect for things you don't intend the user to store".

Yeah.

I also like to use auto more than most people probably, for local variables where the type really ought to be already obvious, or it's really not that important what the exact type is. I really don't like the idea of having to comb through my code to rewrite type names just because I decided to change the return type of some function to something that's close enough to the original type that most code probably doesn't need to care.


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

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.


> Perhaps there's actually a design win to be had here if we can define nostore or something like that as a return qualifier...

I'm not sure I'd like that, actually, since sometimes I *do* want to store a lazy range somewhere.


T

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.

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.