We're #1 on Hacker News at the moment!

[H. S. Teoh]

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

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