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