www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - We're #1 on Hacker News at the moment!

reply Walter Bright <newshound2 digitalmars.com> writes:
https://news.ycombinator.com/news
Apr 28 2020
next sibling parent reply Ethan <gooberman gmail.com> writes:
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

(Spoiler: It's another BetterC thing. Every time I see someone 
post news about BetterC, I wonder how much longer it'll take for 
the PAYG druntime thing to become reality)
Apr 28 2020
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2020 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
 
 (Spoiler: It's another BetterC thing. Every time I see someone post news about 
 BetterC, I wonder how much longer it'll take for the PAYG druntime thing to 
 become reality)


The reason for the non-specific link is your votes aren't counted if you access 
it with the specific one.
Apr 28 2020
next sibling parent Ethan <gooberman gmail.com> writes:
On Tuesday, 28 April 2020 at 11:43:28 UTC, Walter Bright wrote:

 The reason for the non-specific link is your votes aren't 
 counted if you access it with the specific one.


We're an international community here. By the time a large amount 
of us click on the front page, it becomes a detective game to see 

page at the time this post was submitted.

This viewpoint also assumes the majority here will upvote the 
article. I don't have a HN account.
Apr 28 2020
prev sibling parent reply SashaGreat <sasha gmail.com> writes:
On Tuesday, 28 April 2020 at 11:43:28 UTC, Walter Bright wrote:

 The reason for the non-specific link is your votes aren't 
 counted if you access it with the specific one.


How do you know that?

I mean this seems a bit awkward, because if you say is true, I'm 
pretty sure they would know this by setting something trough 
cookies, so if I access the direct link then go to main page and 
finally go back to the link it would work? This sound crazy!

Aren't you mistaken with Bandwagon Effect? Where clicks are 
computed only after sometime later?

Sasha.
Apr 28 2020
parent reply WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 28 April 2020 at 12:49:39 UTC, SashaGreat wrote:

 On Tuesday, 28 April 2020 at 11:43:28 UTC, Walter Bright wrote:

 The reason for the non-specific link is your votes aren't 
 counted if you access it with the specific one.


 How do you know that?

 I mean this seems a bit awkward, because if you say is true, 
 I'm pretty sure they would know this by setting something 
 trough cookies, so if I access the direct link then go to main 
 page and finally go back to the link it would work? This sound 
 crazy!


If they do it, they can just look if you came from the homepage 
because the browser sends where you came from (Referer header)
Apr 28 2020
parent reply SashaGreat <sasha gmail.com> writes:
On Tuesday, 28 April 2020 at 12:52:54 UTC, WebFreak001 wrote:

 On Tuesday, 28 April 2020 at 12:49:39 UTC, SashaGreat wrote:

 On Tuesday, 28 April 2020 at 11:43:28 UTC, Walter Bright wrote:

 The reason for the non-specific link is your votes aren't 
 counted if you access it with the specific one.


 How do you know that?

 I mean this seems a bit awkward, because if you say is true, 
 I'm pretty sure they would know this by setting something 
 trough cookies, so if I access the direct link then go to main 
 page and finally go back to the link it would work? This sound 
 crazy!


 If they do it, they can just look if you came from the homepage 
 because the browser sends where you came from (Referer header)


Will this work even if Not Tracking is enabled?

If it's the case then just refreshing or open the link in another 
page would clear the Referrer Header right?

S.
Apr 28 2020
parent reply Eugene Wissner <belka caraus.de> writes:
On Tuesday, 28 April 2020 at 12:58:15 UTC, SashaGreat wrote:

 On Tuesday, 28 April 2020 at 12:52:54 UTC, WebFreak001 wrote:

 On Tuesday, 28 April 2020 at 12:49:39 UTC, SashaGreat wrote:

 On Tuesday, 28 April 2020 at 11:43:28 UTC, Walter Bright 
 wrote:

 The reason for the non-specific link is your votes aren't 
 counted if you access it with the specific one.


 How do you know that?

 I mean this seems a bit awkward, because if you say is true, 
 I'm pretty sure they would know this by setting something 
 trough cookies, so if I access the direct link then go to 
 main page and finally go back to the link it would work? This 
 sound crazy!


 If they do it, they can just look if you came from the 
 homepage because the browser sends where you came from 
 (Referer header)


 Will this work even if Not Tracking is enabled?

 If it's the case then just refreshing or open the link in 
 another page would clear the Referrer Header right?

 S.


Firefox 76 not tracking mode: The Referer header contains only 
the domain and not the complete URL.

You can disable the Referer header completely, but you probably 
shouldn't; Referer makes it possible to implement cookie-free 
csrf protection. At least sending the domain if you don't change 
the domain - is a good idea (so leave Referer empty if you are 
coming from another site, otherwise send the current domain or 
the complete URL).

Just refreshing the page, doesn't clear the Referer.

To make things more privacy-friendly the Origin header was 
introduced, which behaves similar to the Referer in "not tracking 
mode", but my Firefox doesn't seem to send it (not sure if the 
defaults are different nowadays).
Apr 28 2020
parent WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 28 April 2020 at 13:35:37 UTC, Eugene Wissner wrote:

 On Tuesday, 28 April 2020 at 12:58:15 UTC, SashaGreat wrote:

 On Tuesday, 28 April 2020 at 12:52:54 UTC, WebFreak001 wrote:

 On Tuesday, 28 April 2020 at 12:49:39 UTC, SashaGreat wrote:

 On Tuesday, 28 April 2020 at 11:43:28 UTC, Walter Bright 
 wrote:

 The reason for the non-specific link is your votes aren't 
 counted if you access it with the specific one.


 How do you know that?

 I mean this seems a bit awkward, because if you say is true, 
 I'm pretty sure they would know this by setting something 
 trough cookies, so if I access the direct link then go to 
 main page and finally go back to the link it would work? 
 This sound crazy!


 If they do it, they can just look if you came from the 
 homepage because the browser sends where you came from 
 (Referer header)


 Will this work even if Not Tracking is enabled?

 If it's the case then just refreshing or open the link in 
 another page would clear the Referrer Header right?

 S.


 Firefox 76 not tracking mode: The Referer header contains only 
 the domain and not the complete URL.

 You can disable the Referer header completely, but you probably 
 shouldn't; Referer makes it possible to implement cookie-free 
 csrf protection. At least sending the domain if you don't 
 change the domain - is a good idea (so leave Referer empty if 
 you are coming from another site, otherwise send the current 
 domain or the complete URL).


Malicious sites can disable the Referer header on any requests, 
so it doesn't matter if the user has it on or off if the website 
supports it being off. I have found several security issues by 
people who thought checking the Referer header would work or was 
enough.



 Just refreshing the page, doesn't clear the Referer.

 To make things more privacy-friendly the Origin header was 
 introduced, which behaves similar to the Referer in "not 
 tracking mode", but my Firefox doesn't seem to send it (not 
 sure if the defaults are different nowadays).


Origin is sent when you make requests to other origins or do a 
POST request on any origin. Especially when you are handling 
sensitive simple GET or POST requests you should check this 
header because the browser will just send them instead of 
checking with an OPTIONS request (preflight) before.
Apr 28 2020
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Apr 28 2020
parent reply bachmeier <no spam.net> writes:
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.
Apr 28 2020
parent Ethan <gooberman gmail.com> writes:
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


thread started)
Apr 28 2020
prev sibling parent reply Laust <leaveme with.promises> writes:
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.
Apr 28 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Apr 28 2020
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Apr 28 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Apr 28 2020
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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
Apr 28 2020
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
Apr 28 2020
prev sibling parent reply Ethan <gooberman gmail.com> writes:
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...
Apr 28 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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

-- 
Государство делает вид, что платит нам
зарплату, а мы делаем вид, что работаем.
Apr 28 2020
parent reply Jeff C. <jeffc email.addr> writes:
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.
Apr 28 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Apr 28 2020
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
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.
Apr 28 2020
parent reply Arine <arine1283798123 gmail.com> writes:
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.
Apr 28 2020
parent Atila Neves <atila.neves gmail.com> writes:
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.
Apr 29 2020
prev sibling next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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.
Apr 28 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 28 2020
parent reply Sam E. <sam.e example.org> writes:
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 ¯\_(ツ)_/¯.
Apr 29 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 29 2020