www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Greenwashing

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
 From https://www.investopedia.com/terms/g/greenwashing.asp, the top 
Google search result:

Greenwashing is the process of conveying a false impression or providing 
misleading information about how a company's products are more 
environmentally sound. Greenwashing is considered an unsubstantiated 
claim to deceive consumers into believing that a company's products are 
environmentally friendly.

Paraphrasing for our context:

Greenwashing is the process of conveying a false impression or providing 
misleading information about how a codebase is more memory-safe. 
Greenwashing is considered an unsubstantiated claim to deceive readers 
into believing that a codebase is memory-safe.

If this is greenwashing, then DIP 1028 is doing it.
May 27
next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu 
wrote:
 From https://www.investopedia.com/terms/g/greenwashing.asp, the 
 top Google search result:

 Greenwashing is the process of conveying a false impression or 
 providing misleading information about how a company's products 
 are more environmentally sound. Greenwashing is considered an 
 unsubstantiated claim to deceive consumers into believing that 
 a company's products are environmentally friendly.

 Paraphrasing for our context:

 Greenwashing is the process of conveying a false impression or 
 providing misleading information about how a codebase is more 
 memory-safe. Greenwashing is considered an unsubstantiated 
 claim to deceive readers into believing that a codebase is 
 memory-safe.

 If this is greenwashing, then DIP 1028 is doing it.
I think you're right - unless D has a thorough, rigorously specified static analysis this will be the case (At zero cost, at least). The current efforts to add that seem like they go in the right direction, but I feel like they'll have to have a breaking semantic/syntax change at some point (e.g. the way rust handles references seems much more decidable). FWIW: There's need to be a thorough design first, the current approach to safety seems to spread among dmd like an octopuses tentacles. However, talk is cheap so I'm not complaining about what we have so far.
May 27
prev sibling next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu 
wrote:
 Paraphrasing for our context:

 Greenwashing <...>
I propose safewashing
May 27
next sibling parent David Gileadi <gileadisNOSPM gmail.com> writes:
On 5/27/20 5:25 AM, welkam wrote:
 On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu wrote:
 Paraphrasing for our context:

 Greenwashing <...>
I propose safewashing
The bikeshed should clearly be green! ;)
May 27
prev sibling parent user1234 <user1234 12.de> writes:
On Wednesday, 27 May 2020 at 12:25:48 UTC, welkam wrote:
 On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu 
 wrote:
 Paraphrasing for our context:

 Greenwashing <...>
I propose safewashing
There's also what I call "digital washing". The process for a tech company to advertise how repespectful it is toward privacy and consumer data or how friendly it is toward open source software. Digital washing also includes Green washing when the company advertises that their datacenter use solar energy for example.
May 27
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, May 27, 2020 5:37:17 AM MDT Andrei Alexandrescu via Digitalmars-
d wrote:
  From https://www.investopedia.com/terms/g/greenwashing.asp, the top
 Google search result:

 Greenwashing is the process of conveying a false impression or providing
 misleading information about how a company's products are more
 environmentally sound. Greenwashing is considered an unsubstantiated
 claim to deceive consumers into believing that a company's products are
 environmentally friendly.

 Paraphrasing for our context:

 Greenwashing is the process of conveying a false impression or providing
 misleading information about how a codebase is more memory-safe.
 Greenwashing is considered an unsubstantiated claim to deceive readers
 into believing that a codebase is memory-safe.

 If this is greenwashing, then DIP 1028 is doing it.
Indeed. A number of us have argued with Walter that DIP 1028 turns safe into a lie and that the compiler should _never_ treat anything as safe unless it can mechanicaly verify it or the programmer has explicitly marked it with trusted. But for some reason, he thinks that having a "special rule" that non-extern(D) function declarations aren't treated as safe by default like all of the functions that the compiler can actually mechanically verify adds too much complexity to the language. safe isn't necessarily a problem, but safe shouldn't have a huge blown in it in the process. Based on some of Walter's comments, it also sounds like he intends to make nothrow the default in another DIP, which is also a terrible idea. I'm increasingly worried about the future of D with some of where these DIPs are going. - Jonathan M Davis
May 27
next sibling parent <a a.com> writes:
On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:

I'm increasingly worried about the future
 of D with some of where these DIPs are going.

 - Jonathan M Davis
I foresee three things that could happen : 1. People get annoyed and stop using D. 2. Tools and editor features(think like dfmt) are added that slap system everywhere unless safe or trusted is specified.(the most probable in my opinion) 3. DMD gets forked and/or third party compilers keep system as default No matter what ends up happening i think there is reason to worry...
May 27
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/27/20 2:50 PM, Jonathan M Davis wrote:

 Based on some of Walter's comments, it also sounds like he intends to make
 nothrow the default in another DIP, which is also a terrible idea. I'm
 increasingly worried about the future of D with some of where these DIPs are
 going.
In general, I think safe, nothrow, nogc, and pure by default have some benefits on code that is actually compiled by a D compiler. Simply because most of the time, code you write is generally in these categories, but isn't marked as such. Imagine instead of any of this, you simply wrote all functions that are not marked as no-arg templates. This would change nothing (only one symbol is generated anyway, Stefan), but provide a much better experience for users who care about certain attributes. Perhaps instead of making these things the default, we instead made *inference* the default. Then we could have something like noinfer (please, this is not a proposal, don't focus on the name) which would declare that you intend to make this something that the source code will not be available. Perhaps the focus on "X by default" is just looking at the wrong aspect. -Steve
May 27
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 27 May 2020 at 21:01:51 UTC, Steven Schveighoffer 
wrote:
 Perhaps instead of making these things the default, we instead 
 made *inference* the default.
Thats a brilliant idea, however the issue of extern still remains with the additional complication of mangling due to attributes and also separate compilation/.di files. Separate compilation may be a lot slower if inference must be done for function bodies. For anyone that experiences significant slowdowns as a result I see no harm in a switch to disable it.
May 27
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 28 May 2020 at 00:51:52 UTC, Nicholas Wilson wrote:
 Thats a brilliant idea, however the issue of extern still 
 remains with the additional complication of mangling due to 
 attributes and also separate compilation/.di files.
extern ones (including probably abstract/interface methods) require an annotation, otherwise it is inferred. Then you can explicitly put a thing on if you want a guarantee of it (as a user) or to provide a guarantee of it (as a lib designer / interface publisher). It really does lead to everyone wins... and this pattern can be extended to other functions as well. And we have precedent with templates.
 Separate compilation may be a lot slower if inference must be 
 done for function bodies.
Extremely unlikely - it already does those checks to confirm the annotation anyway!
May 27
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 28 May 2020 at 00:59:30 UTC, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 00:51:52 UTC, Nicholas Wilson wrote:
 Thats a brilliant idea, however the issue of extern still 
 remains with the additional complication of mangling due to 
 attributes and also separate compilation/.di files.
extern ones (including probably abstract/interface methods) require an annotation, otherwise it is inferred.
I meant as in they still require default of _something_, and given recent times that contention is unlikely to go away. I hadn't though about inheritance at all, thats tricky.
 Extremely unlikely - it already does those checks to confirm 
 the annotation anyway!
Ah, I didn't know that! All the more reason for all at once (or at least package at a time)!
May 27
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/27/20 8:59 PM, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 00:51:52 UTC, Nicholas Wilson wrote:
 Separate compilation may be a lot slower if inference must be done for 
 function bodies.
Extremely unlikely - it already does those checks to confirm the annotation anyway!
This isn't something I thought of. I am surprised if the compiler semantically analyzes only-imported functions. In fact, I'm almost sure this doesn't happen (based on D's track record with unittests). But in practice much of D is actually templates already. I doubt this would have a tremendous impact. In any case, this COULD be mitigated via some sort of intermediate form, or .di files. -Steve
May 27
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 28 May 2020 at 01:20:31 UTC, Steven Schveighoffer 
wrote:
 This isn't something I thought of. I am surprised if the 
 compiler semantically analyzes only-imported functions. In 
 fact, I'm almost sure this doesn't happen (based on D's track 
 record with unittests).
aaaargh, I'm sorry, you're right. I forgot I habitually use -i now which brings it in for full analysis. It only does this for auto functions and templates in imported modules right now.
May 27
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/27/20 9:32 PM, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 01:20:31 UTC, Steven Schveighoffer wrote:
 This isn't something I thought of. I am surprised if the compiler 
 semantically analyzes only-imported functions. In fact, I'm almost 
 sure this doesn't happen (based on D's track record with unittests).
aaaargh, I'm sorry, you're right. I forgot I habitually use -i now which brings it in for full analysis. It only does this for auto functions and templates in imported modules right now.
Even so, things like DUB could automatically build .di files if this was an issue. -Steve
May 27
prev sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 28/05/2020 12:51 PM, Nicholas Wilson wrote:
 
 Thats a brilliant idea, however the issue of extern still remains with 
 the additional complication of mangling due to attributes and also 
 separate compilation/.di files.
.di files are not an issue. When the compiler writes them out, just include the attribute with it... Under such a scheme the compiler may not even know it was inferred.
May 28
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 27 May 2020 at 21:01:51 UTC, Steven Schveighoffer 
wrote:
 On 5/27/20 2:50 PM, Jonathan M Davis wrote:

 [...]
In general, I think safe, nothrow, nogc, and pure by default have some benefits on code that is actually compiled by a D compiler. Simply because most of the time, code you write is generally in these categories, but isn't marked as such. [...]
+1 ....
May 28
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
 Based on some of Walter's comments, it also sounds like he 
 intends to make nothrow the default in another DIP, which is 
 also a terrible idea. I'm increasingly worried about the future 
 of D with some of where these DIPs are going.

 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
May 27
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d wrote:
 On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
 Based on some of Walter's comments, it also sounds like he
 intends to make nothrow the default in another DIP, which is
 also a terrible idea. I'm increasingly worried about the future
 of D with some of where these DIPs are going.

 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite. In general, exceptions are by far the best way to deal with error conditions that we have. They clean up code considerably and make it much harder for error conditions to be ignored or eaten. Alternatives such as error code are terrible in comparison. We do end up with far less code being able to be nothrow in D than we should because of how autodecoding works, but it's still the case that _way_ more than 97% of the code out there is going to potentially throw exceptions - especially in applications that have to deal with users and/or the network. Propagating error conditions without exceptions gets disgusting fast. There's no question that there is code that cannot afford the extra cost of exception handling and has to do something else, but it's much more error-prone and isn't the norm for programs in general. And of course, in some cases, exceptions just plain don't make sense (e.g. the fact that std.utf.validate throws instead of returning bool is terrible), so it's not like they're always the appropriate solution or used correctly. However, in general, they most definitely should be the default for how your typical application deals with error conditions. Anything else leads to far more bugs. I would have thought that the experience of the programming community at large at this point would make that pretty clear. Exceptions are by no means perfect, but for the general case, they're the best way that we have to cleanly propagate error conditions and avoid having error conditions be ignored or lost. Having nothrow be the default would encourage people to not use exceptions (leading to worse code in general) and would result in a _lot_ more attributes being needed on the code that does use exceptions. Certainly, I know that for the libraries and applications that I've worked on for most of my career (be it in D or some other language), if nothrow were the default, those libraries and applications would have to be marking throw all over the place (which is in fact basically what happens in Java, though they have they extra annoyance of having to mark _which_ exception types can be thrown, which has proven to be a terrible idea and which we fortunately have avoided in D). I think that it's great that we have nothrow for those cases where it's appropriate, but I don't think that it makes sense at all to assume that that's the _normal_ situation. In any case, when the topic has come up before, plenty of people have raised similar complaints to mine, so if/when Walter puts forth a DIP proposing nothrow to be the default as I think that he's planning on doing, I expect that he'll get quite a few dissenting opinions on it - likely far more than for making safe the default. Of course, since he won't listen when pretty much everyone else disagrees with him on what to do with extern(C) with safe being the default, who knows how well _that_ will go... - Jonathan M Davis
May 27
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/27/20 8:31 PM, Jonathan M Davis wrote:
 On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d wrote:
 On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
 Based on some of Walter's comments, it also sounds like he
 intends to make nothrow the default in another DIP, which is
 also a terrible idea. I'm increasingly worried about the future
 of D with some of where these DIPs are going.

 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite.
It actually doesn't matter what's more common (and I agree with Jonathan, there's actually a lot of throwing calls because of the calls that you make into other functions). What matters is that there are functions that are actually nothrow that aren't marked nothrow. Hence the desire that these functions should actually be marked nothrow implicitly so people who care about that can just use the functions without issue. -Steve
May 27
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 28 May 2020 at 01:23:31 UTC, Steven Schveighoffer 
wrote:
 On 5/27/20 8:31 PM, Jonathan M Davis wrote:
 On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via 
 Digitalmars-d wrote:
 On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis 
 wrote:
 Based on some of Walter's comments, it also sounds like he
 intends to make nothrow the default in another DIP, which is
 also a terrible idea. I'm increasingly worried about the 
 future
 of D with some of where these DIPs are going.

 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite.
It actually doesn't matter what's more common (and I agree with Jonathan, there's actually a lot of throwing calls because of the calls that you make into other functions). What matters is that there are functions that are actually nothrow that aren't marked nothrow. Hence the desire that these functions should actually be marked nothrow implicitly so people who care about that can just use the functions without issue. -Steve
What make me feel "mhmm" is that the motivation is always "because no throw is speediest, so should be the default" ... While I'm ok the "pay as you go" concept, I still think that a sane default for writing good code is still preferable: tuning the hot path is still the way to go if you care for speed. The same for switching from "virtual by default" to "final by default", the motivation should not be "because the code is speedier", but because it's the best way to promote encapsulation of the class public API (as W&A agreed years ago ...) The same for safety, if you don't care, well, slap system everywhere, or trusted if you want, anyway you are not caring. You just CAN code fast in that way. BUT if you care, you should have all the aid from the compiler to archive it, because writing safe code is much more task, so safe only for compiler checked code.
May 28
next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 28 May 2020 at 07:36:05 UTC, Paolo Invernizzi wrote:

 tuning the hot path is still the way to go if you care for 
 speed.
You havent done many optimizations have you? The few hot spots happens when you have a simple program or there were no attempts made to optimize the code. If you profile say DMD code you will find that there are no hot spots. If you want the code to be fast you need to care about all of it. Some parts need more attention than others but you still need to care about it.
May 28
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 28 May 2020 at 12:21:31 UTC, welkam wrote:
 On Thursday, 28 May 2020 at 07:36:05 UTC, Paolo Invernizzi 
 wrote:

 tuning the hot path is still the way to go if you care for 
 speed.
You havent done many optimizations have you?
For sure I have ...
 The few hot spots happens when you have a simple program or 
 there were no attempts made to optimize the code.
Granted
 If you profile say DMD code you will find that there are no hot 
 spots. If you want the code to be fast you need to care about 
 all of it. Some parts need more attention than others but you 
 still need to care about it.
I'm on that boat, but I think that this is not always the state of affairs, it really depend on the domain of the application. DMD codebase is well known, written since a couple of decades and based (for the backend, for example) on the shoulders of DMC ... and written by one of the most brilliant programmers in the whole world ... Walter Bright: I will be surprised, if there's an hot path to squeeze in it. Anyway, I think you are right talking in general case, you still need to care about the whole .. and, figure out, we work in the real-time domain, as most of our customers are medical companies, so I understand very well what you are referring to ... :-P
May 28
parent welkam <wwwelkam gmail.com> writes:
On Thursday, 28 May 2020 at 15:23:49 UTC, Paolo Invernizzi wrote:
 On Thursday, 28 May 2020 at 12:21:31 UTC, welkam wrote:
 On Thursday, 28 May 2020 at 07:36:05 UTC, Paolo Invernizzi 
 wrote:

 tuning the hot path is still the way to go if you care for 
 speed.
You havent done many optimizations have you?
For sure I have ...
Am I the only one that find the common saying that 20% of code is responsible for 80% of runtime to be not true? In my experience its either 5% eating up 90% of runtime (a stupid mistake) or the slowness spread out trough out the codebase. Have I not seen enough cases?
May 28
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/28/20 3:36 AM, Paolo Invernizzi wrote:
 On Thursday, 28 May 2020 at 01:23:31 UTC, Steven Schveighoffer wrote:
 On 5/27/20 8:31 PM, Jonathan M Davis wrote:
 On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d wrote:
 On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
 Based on some of Walter's comments, it also sounds like he
 intends to make nothrow the default in another DIP, which is
 also a terrible idea. I'm increasingly worried about the future
 of D with some of where these DIPs are going.

 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite.
It actually doesn't matter what's more common (and I agree with Jonathan, there's actually a lot of throwing calls because of the calls that you make into other functions). What matters is that there are functions that are actually nothrow that aren't marked nothrow. Hence the desire that these functions should actually be marked nothrow implicitly so people who care about that can just use the functions without issue.
What make me feel "mhmm" is that the motivation is always "because no throw is speediest, so should be the default" ...
That's not the motivation for the default. throwing code can call nothrow code. Nothrow code cannot call throw code (without doing something about the exceptions). If code is actually nothrow (meaning it does not ever throw any exceptions) but not marked as nothrow, then it's an attribute away from being more useful. If we make nothrow the default, then code that already is nothrow, but simply not marked, now becomes more useful. Same goes for safe, nogc, pure. This is about properly marking code, not about speed. But I'm thinking we are approaching this wrong. We should simply make inference the default, and opt out by using an attribute or some other mechanism (pragma?). It would have the same effect but not break all code in existence. -Steve
May 28
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 29/05/2020 3:00 AM, Steven Schveighoffer wrote:
 But I'm thinking we are approaching this wrong. We should simply make 
 inference the default, and opt out by using an attribute or some other 
 mechanism (pragma?). It would have the same effect but not break all 
 code in existence.
I had the same realization a few days ago. The fact that you have to type safe and system at all is the real problem. Apart from function pointers and explicit overriding you should not be writing them normally. .di files would be generated with the annotations regardless of if it is supplied by user or not. The trick to get this to work well AND have false positives (i.e. a function that is system but appears safe and vice versa) is to do the inferring as early as possible. This sounds crazy, but it would force people to consider if it should be trusted or if it was just something that needs fixing. The goal would be to make safe transitively poison the call stack to require fixing. But if most D code already is safe, what is there to worry about?
May 28
prev sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 28 May 2020 at 15:00:11 UTC, Steven Schveighoffer 
wrote:
 On 5/28/20 3:36 AM, Paolo Invernizzi wrote:
 On Thursday, 28 May 2020 at 01:23:31 UTC, Steven Schveighoffer 
 wrote:
 On 5/27/20 8:31 PM, Jonathan M Davis wrote:
 On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via 
 Digitalmars-d wrote:
 On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis 
 wrote:
 Based on some of Walter's comments, it also sounds like he
 intends to make nothrow the default in another DIP, which 
 is
 also a terrible idea. I'm increasingly worried about the 
 future
 of D with some of where these DIPs are going.

 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite.
It actually doesn't matter what's more common (and I agree with Jonathan, there's actually a lot of throwing calls because of the calls that you make into other functions). What matters is that there are functions that are actually nothrow that aren't marked nothrow. Hence the desire that these functions should actually be marked nothrow implicitly so people who care about that can just use the functions without issue.
What make me feel "mhmm" is that the motivation is always "because no throw is speediest, so should be the default" ...
That's not the motivation for the default.
DIP 1029, Rationale: "The problem is that exceptions are not cost-free, even in code that never throws. Exceptions should therefore be opt-in, not opt-out. Although this DIP does not propose making exceptions opt-in, the throw attribute is a key requirement for it. The attribute also serves well as documentation that yes, a function indeed can throw." Maybe I'm wrong, but when Walter uses "not cost-free" he seldom refers to something else than ... speed.
May 28
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/28/20 11:16 AM, Paolo Invernizzi wrote:
 On Thursday, 28 May 2020 at 15:00:11 UTC, Steven Schveighoffer wrote:
 On 5/28/20 3:36 AM, Paolo Invernizzi wrote:
 What make me feel "mhmm" is that the motivation is always "because no 
 throw is speediest, so should be the default" ...
That's not the motivation for the default.
DIP 1029, Rationale: "The problem is that exceptions are not cost-free, even in code that never throws. Exceptions should therefore be opt-in, not opt-out. Although this DIP does not propose making exceptions opt-in, the throw attribute is a key requirement for it. The attribute also serves well as documentation that yes, a function indeed can throw." Maybe I'm wrong, but when Walter uses "not cost-free" he seldom refers to something else than ... speed.
I should be clearer that MY motivation for having these things be the default is so that more code can be used in more situations. Walter's motivation may differ. The fact that this function is not nogc safe pure nothrow is a failure of the language: int multiply(int x, int y) { return x * y; } I shouldn't have to have attribute soup everywhere, and most likely I'm not going to bother. The motivation for the existence of nothrow in general is to avoid the cost of exception handling. But the motivation of making it the *default* is because people just don't mark their nothrow functions nothrow. The easier default is nothrow because it is callable from either situation. In other words, it enables more code. -Steve
May 28
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 28 May 2020 at 15:28:02 UTC, Steven Schveighoffer 
wrote:
 On 5/28/20 11:16 AM, Paolo Invernizzi wrote:
 [...]
I should be clearer that MY motivation for having these things be the default is so that more code can be used in more situations. Walter's motivation may differ. The fact that this function is not nogc safe pure nothrow is a failure of the language: int multiply(int x, int y) { return x * y; } I shouldn't have to have attribute soup everywhere, and most likely I'm not going to bother. The motivation for the existence of nothrow in general is to avoid the cost of exception handling. But the motivation of making it the *default* is because people just don't mark their nothrow functions nothrow. The easier default is nothrow because it is callable from either situation. In other words, it enables more code. -Steve
I can agree with you, but I would like to see a solid rationale for that kind of switches. But I guess that we should only wait till the discussion on the future DIP around that.
May 28
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/28/20 11:16 AM, Paolo Invernizzi wrote:
 On Thursday, 28 May 2020 at 15:00:11 UTC, Steven Schveighoffer wrote:
 On 5/28/20 3:36 AM, Paolo Invernizzi wrote:
 On Thursday, 28 May 2020 at 01:23:31 UTC, Steven Schveighoffer wrote:
 On 5/27/20 8:31 PM, Jonathan M Davis wrote:
 On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d 
 wrote:
 On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
 Based on some of Walter's comments, it also sounds like he
 intends to make nothrow the default in another DIP, which is
 also a terrible idea. I'm increasingly worried about the future
 of D with some of where these DIPs are going.

 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite.
It actually doesn't matter what's more common (and I agree with Jonathan, there's actually a lot of throwing calls because of the calls that you make into other functions). What matters is that there are functions that are actually nothrow that aren't marked nothrow. Hence the desire that these functions should actually be marked nothrow implicitly so people who care about that can just use the functions without issue.
What make me feel "mhmm" is that the motivation is always "because no throw is speediest, so should be the default" ...
That's not the motivation for the default.
DIP 1029, Rationale: "The problem is that exceptions are not cost-free, even in code that never throws. Exceptions should therefore be opt-in, not opt-out. Although this DIP does not propose making exceptions opt-in, the throw attribute is a key requirement for it. The attribute also serves well as documentation that yes, a function indeed can throw." Maybe I'm wrong, but when Walter uses "not cost-free" he seldom refers to something else than ... speed.
There's cognitive cost, too. Coding with functions that throw is a lot more difficult.
May 28
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/27/2020 5:31 PM, Jonathan M Davis wrote:
  since he won't listen
More accurately "does not agree".
May 28
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 28 May 2020 at 09:33:26 UTC, Walter Bright wrote:
 On 5/27/2020 5:31 PM, Jonathan M Davis wrote:
  since he won't listen
More accurately "does not agree".
...and fails to present sound arguments in defense of his position. The problem is not disagreeing.
May 28
prev sibling parent welkam <wwwelkam gmail.com> writes:
On Thursday, 28 May 2020 at 09:33:26 UTC, Walter Bright wrote:
 On 5/27/2020 5:31 PM, Jonathan M Davis wrote:
  since he won't listen
More accurately "does not agree".
1. D`s safe is not powerful enough to be used with manual memory management. 2. Because of 1 people dont see enough value in using safe in their code especially if it interfaces with C libraries. 3. Because of 2 when safe becomes default, people will use the least effort required way to shut up the compiler. Meaning safe: at top level of a module. 4. Because of 3 you think compiler should mark extern C functions as safe by default. Most of the talks in this forum focused on 4. I think people missed the forest for the trees. The real problem is 1. As long as there are no way to mechanically verify use of malloc and free to be safe, or at least wrap in easy to use safe constructs, I dont see any way how DIP 1028 can be changed to not be problematic. As long as safe is not useful enough all potential outcomes of DIP 1028 are bad. But I am just random guy on the internet.
May 28
prev sibling next sibling parent welkam <wwwelkam gmail.com> writes:
On Thursday, 28 May 2020 at 00:31:09 UTC, Jonathan M Davis wrote:
 There's no question that there is code that cannot afford the 
 extra cost of exception handling and has to do something else, 
 but it's much more error-prone and isn't the norm for programs 
 in general
I think you misunderstood why some people for example in game engine development are against the use of exceptions. When you have complex system and you have to verify that right things are done trough all possible control flow paths anything that complicates this is frowned upon. What exceptions do is they inflate control flow graph making almost impossible to verify that your system does the right thing in all situations and that would increase bugs in your system
May 28
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 28 May 2020 at 00:31:09 UTC, Jonathan M Davis wrote:
 On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via 
 Digitalmars-d wrote:
 On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis 
 wrote:
 Based on some of Walter's comments, it also sounds like he 
 intends to make nothrow the default in another DIP, which is 
 also a terrible idea. I'm increasingly worried about the 
 future of D with some of where these DIPs are going.

 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite. <snip>
I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.
May 28
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 28.05.20 22:41, Meta wrote:
 On Thursday, 28 May 2020 at 00:31:09 UTC, Jonathan M Davis wrote:
 On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d wrote:
 On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
 Based on some of Walter's comments, it also sounds like he > 
intends to make nothrow the default in another DIP, which is > also a terrible idea. I'm increasingly worried about the > future of D with some of where these DIPs are going.
 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite. <snip>
I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.
http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.
May 29
parent reply Meta <jared771 gmail.com> writes:
On Friday, 29 May 2020 at 08:52:14 UTC, Timon Gehr wrote:
 I find that response surprising, given that you used to use 
 Haskell (do you still?), which gets along fine without 
 exceptions.
http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.
I'm going to step up the pedantry and say that this proves my assertion; Haskell (the language) gets along fine without exceptions, but they're there for you to use as a library, only if you want to.
May 29
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 29 May 2020 at 12:40:45 UTC, Meta wrote:
 On Friday, 29 May 2020 at 08:52:14 UTC, Timon Gehr wrote:
 I find that response surprising, given that you used to use 
 Haskell (do you still?), which gets along fine without 
 exceptions.
http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.
I'm going to step up the pedantry and say that this proves my assertion; Haskell (the language) gets along fine without exceptions, but they're there for you to use as a library, only if you want to.
Forgoing exceptions in D would be a lot more palatable if we had Currently, if you want to ensure that callers of your function can't ignore errors by accident, your only option in D is to throw an exception.
May 29
parent Meta <jared771 gmail.com> writes:
On Friday, 29 May 2020 at 13:20:52 UTC, Paul Backus wrote:
 On Friday, 29 May 2020 at 12:40:45 UTC, Meta wrote:
 I'm going to step up the pedantry and say that this proves my 
 assertion; Haskell (the language) gets along fine without 
 exceptions, but they're there for you to use as a library, 
 only if you want to.
Forgoing exceptions in D would be a lot more palatable if we Currently, if you want to ensure that callers of your function can't ignore errors by accident, your only option in D is to throw an exception.
I agree, it would be nice to be able to express that in D. You can sort of emulate it at runtime: struct MustUse(T) { T payload; bool used; ref T use() { used = true; return payload; } alias use this; //Or, probably better, call use() manually ~this() { assert(used, MustUse.stringof ~ " must be used, but it wasn't"); } } MustUse!string read(File f) { ... }
May 29
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 29.05.20 14:40, Meta wrote:
 On Friday, 29 May 2020 at 08:52:14 UTC, Timon Gehr wrote:
 I find that response surprising, given that you used to use Haskell 
 (do you still?), which gets along fine without exceptions.
http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.
I'm going to step up the pedantry and say that this proves my assertion; Haskell (the language) gets along fine without exceptions, but they're there for you to use as a library, only if you want to.
Prelude> case (1,1) of (2,2) -> 0 *** Exception: <interactive>:4:1-24: Non-exhaustive patterns in case
May 29
parent Meta <jared771 gmail.com> writes:
On Friday, 29 May 2020 at 20:02:37 UTC, Timon Gehr wrote:
 On 29.05.20 14:40, Meta wrote:
 On Friday, 29 May 2020 at 08:52:14 UTC, Timon Gehr wrote:
 I find that response surprising, given that you used to use 
 Haskell (do you still?), which gets along fine without 
 exceptions.
http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.
I'm going to step up the pedantry and say that this proves my assertion; Haskell (the language) gets along fine without exceptions, but they're there for you to use as a library, only if you want to.
Prelude> case (1,1) of (2,2) -> 0 *** Exception: <interactive>:4:1-24: Non-exhaustive patterns in case
Okay, I'll concede that one. I forgot that non-exhaustive patterns throw exceptions; I thought I remembered them raising errors. Let's talk about Rust instead, then, which 100% absolutely does not have exceptions. They seem to make do with Option/Result/try (though I guess since they're monads you'd consider those equivalent to exceptions, but they don't behave like exceptions as they're just sugar over pattern matching).
May 29
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, May 28, 2020 2:41:43 PM MDT Meta via Digitalmars-d wrote:
 On Thursday, 28 May 2020 at 00:31:09 UTC, Jonathan M Davis wrote:
 On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via

 Digitalmars-d wrote:
 On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis

 wrote:
 Based on some of Walter's comments, it also sounds like he
 intends to make nothrow the default in another DIP, which is
 also a terrible idea. I'm increasingly worried about the
 future of D with some of where these DIPs are going.

 - Jonathan M Davis
What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
If anything, I would say the opposite. <snip>
I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.
Functional languages are a very different beast from imperative or multi-paradigm languages. So, to a great extent, we're talking apples and oranges when comparing them. Regardless, Haskell avoids some of the pitfalls of not using exceptions while being pretty firmly stuck with others. Because it's purely functional, you can't easily ignore the results of functions, which makes error-codes (or monads with error reporting) less error-prone than they are in languages like C++, Java, or D, but the result still clutters the code considerably. It's very typical in Haskell that you're stuck passing monads in one form or another well up the call stack, so the error-handling effectively infects the whole program instead of being segregated to the portions where it's most appropriate to deal with it. And of course, it gets that much more fun when you need to be passing multiple things up the call stack via monads. Ultimately though, Haskell is so different from D that it's hard to really talk about best practices from one applying to the other. Personally, I think that it's great to spend time using a functional language as your main language for a while, because it forces you to get better at functional programming practices such as recursion - but it forces it by not letting you have the full toolbox like a multi-paradigm language does. I'm _much_ more comfortable with stuff like templates and range-based code than I would have been had I not spent a fair bit of time programming in Haskell previously, but honestly, I hate functional languages. They're far too restrictive, and I don't understand how anyone can seriously program in them professionally. Debugging Haskell is a disgusting, unpleasant process in comparison to an imperative or OO language. I highly recommend that programmers spend some time in functional land to improve their skills, but I would never want to program with such tools for a living. exceptions are by far the cleanest and least error-prone way to deal with error conditions in general. They definitely aren't always appropriate, but for your average program, they're how I'd expect most error-handling to be done. - Jonathan M Davis
May 29
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 29 May 2020 at 22:19:37 UTC, Jonathan M Davis wrote:

 Personally, I think that it's great to spend time using a 
 functional language as your main language for a while, because 
 it forces you to get better at functional programming practices 
 such as recursion - but it forces it by not letting you have 
 the full toolbox like a multi-paradigm language does. I'm 
 _much_ more comfortable with stuff like templates and 
 range-based code than I would have been had I not spent a fair 
 bit of time programming in Haskell previously, but honestly, I 
 hate functional languages. They're far too restrictive, and I 
 don't understand how anyone can seriously program in them 
 professionally. Debugging Haskell is a disgusting, unpleasant 
 process in comparison to an imperative or OO language. I highly 
 recommend that programmers spend some time in functional land 
 to improve their skills, but I would never want to program with 
 such tools for a living.
If someone wants to practise or have fun with a functional language, and at the some time have some concrete and good tool for a real job, I suggest giving a try to Elm. It's rock solid, and much more easy then Haskell (its compiler is written in Haskell), and you can learn and be profitable in a really short time. Bonus point, fantastic error messages provided and ... well you can avoid Javascript!
May 30
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Wednesday, 27 May 2020 at 23:57:00 UTC, Meta wrote:
 What's wrong with nothrow by default? Probably 97% of code 
 doesn't need to throw exceptions.
One point of view can be to consider the consequences of fixing code that incorrectly uses the default. If we have throws-by-default, then marking an existing non-templated method ` nothrow` is not a breaking change. If we have nothrow-by-default, then marking an existing non-templated method ` throws` is a breaking change. Another point of view could be that there's a benefit to being permissive by default in terms of what the developer can do.
May 28
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 28 May 2020 at 13:42:24 UTC, Joseph Rushton Wakeling 
wrote:
 One point of view can be to consider the consequences of fixing 
 code that incorrectly uses the default.
The beauty of inferred by default is neither are breaking changes. ...and both are breaking changes, but an inferred default is explicitly not guaranteed to remain the same across version updates, so people should be more expecting of it to change.
May 28
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 28 May 2020 at 13:53:39 UTC, Adam D. Ruppe wrote:
 The beauty of inferred by default is neither are breaking 
 changes.
Not sure I agree about that TBH. Inferred-by-default just means the function signature doesn't by default tell you anything about what properties you can rely on, and any change to the implementation may alter the available properties, without any external sign that this has happened.
May 28
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 28 May 2020 at 14:53:26 UTC, Joseph Rushton Wakeling 
wrote:
 On Thursday, 28 May 2020 at 13:53:39 UTC, Adam D. Ruppe wrote:
 The beauty of inferred by default is neither are breaking 
 changes.
Not sure I agree about that TBH. Inferred-by-default just means the function signature doesn't by default tell you anything about what properties you can rely on, and any change to the implementation may alter the available properties, without any external sign that this has happened.
... which OK, you explicitly did acknowledge, but the point is, this is exactly why I don't like inferred-by-default :-)
May 28
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/28/20 10:53 AM, Joseph Rushton Wakeling wrote:
 On Thursday, 28 May 2020 at 13:53:39 UTC, Adam D. Ruppe wrote:
 The beauty of inferred by default is neither are breaking changes.
Not sure I agree about that TBH.  Inferred-by-default just means the function signature doesn't by default tell you anything about what properties you can rely on, and any change to the implementation may alter the available properties, without any external sign that this has happened.
1. Templates already do this, and it has not been a problem (much of Phobos and much of what I've written is generally templates). 2. If we went to an "inferred-by-default" regime, there would have to be a way to opt-out of it, to allow for crafting attributes of public extern functions. 3. You would still need to specify exact attributes for virtual functions. 4. Documentation should show the inferred attributes IMO (not sure if this already happens for auto functions for example). 5. Yes, inferred attributes might change. This would be a breaking change. It might be a breaking change for others where it is not for the library/function in question. But it would still be something that IMO would require a deprecation period. For things outside our control, it's very possible that these changes would be done anyway even if they were actual attributes. 6. One might also take the view that a lack of attributes means the function may or may not have those attributes inferred in the future (i.e. it's not part of the API). I think much code is already written this way. -Steve
May 28
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer 
wrote:
 Not sure I agree about that TBH.  Inferred-by-default just 
 means the function signature doesn't by default tell you 
 anything about what properties you can rely on, and any change 
 to the implementation may alter the available properties, 
 without any external sign that this has happened.
1. Templates already do this, and it has not been a problem (much of Phobos and much of what I've written is generally templates).
Yes, but the user tends to have a lot of control there in practice, by what template arguments they pass. So the template is less of a black box of surprise. I also think there's a bit of an implicit motivation for an author of templated code to try and _make_ the template args the dominant factor there (because that makes the template more usable).
May 28
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/28/20 11:30 AM, Joseph Rushton Wakeling wrote:
 On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer wrote:
 Not sure I agree about that TBH.  Inferred-by-default just means the 
 function signature doesn't by default tell you anything about what 
 properties you can rely on, and any change to the implementation may 
 alter the available properties, without any external sign that this 
 has happened.
1. Templates already do this, and it has not been a problem (much of Phobos and much of what I've written is generally templates).
Yes, but the user tends to have a lot of control there in practice, by what template arguments they pass.  So the template is less of a black box of surprise.  I also think there's a bit of an implicit motivation for an author of templated code to try and _make_ the template args the dominant factor there (because that makes the template more usable).
I think a ton of templates get written without considering attribute inference at all. It just happens to work because the compiler is guaranteed to have all the source. I've seen people change a function in to a no-arg template function not even for inference, but to ensure the compiler only generates code if called. All of a sudden, it gets a new set of attributes, and nobody complains. The most pleasant thing about template inference is that it generally works out well because it provides the most restrictive attributes it can. It doesn't get in the way of the author who doesn't care about attributes or the user who does care. But it can also blow up if you can't figure out why some inference is happening and you expect something different. I think in addition to such a change to inference by default the compiler should provide a mechanism to explain how it infers things so you can root out the cause of it. I'd like to have this feature regardless of any defaults. -Steve
May 28
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer 
wrote:
 2. If we went to an "inferred-by-default" regime, there would 
 have to be a way to opt-out of it, to allow for crafting 
 attributes of public extern functions.
You'd just have to write them out there.
 4. Documentation should show the inferred attributes IMO (not 
 sure if this already happens for auto functions for example).
Eeeeeeh, I'd be ok with that but it would need to actually point out that it was inferred - that this is NOT a promise of forward compatibility, it just happens to be so in this version
 6. One might also take the view that a lack of attributes means 
 the function may or may not have those attributes inferred in 
 the future (i.e. it's not part of the API). I think much code 
 is already written this way.
yes, i tend to explicitly write it out if im making a point about it.
May 28
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/28/20 12:39 PM, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer wrote:
 2. If we went to an "inferred-by-default" regime, there would have to 
 be a way to opt-out of it, to allow for crafting attributes of public 
 extern functions.
You'd just have to write them out there.
Not possible in some cases ( throws, gc, impure)
 
 4. Documentation should show the inferred attributes IMO (not sure if 
 this already happens for auto functions for example).
Eeeeeeh, I'd be ok with that but it would need to actually point out that it was inferred - that this is NOT a promise of forward compatibility, it just happens to be so in this version
Sure, that's a reasonable expectation. -steve
May 28
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 28 May 2020 at 16:47:01 UTC, Steven Schveighoffer 
wrote:
 On 5/28/20 12:39 PM, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer 
 wrote:
 2. If we went to an "inferred-by-default" regime, there would 
 have to be a way to opt-out of it, to allow for crafting 
 attributes of public extern functions.
You'd just have to write them out there.
Not possible in some cases ( throws, gc, impure)
 
 4. Documentation should show the inferred attributes IMO (not 
 sure if this already happens for auto functions for example).
Eeeeeeh, I'd be ok with that but it would need to actually point out that it was inferred - that this is NOT a promise of forward compatibility, it just happens to be so in this version
Sure, that's a reasonable expectation. -steve
I am all for nonothrow and nononothrow (which does not allow asserts :))
May 28
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 28 May 2020 at 18:09:51 UTC, Stefan Koch wrote:
 I am all for nonothrow and nononothrow (which does not allow 
 asserts :))
nonononononotheresnolimits ;-)
May 28
parent H. S. Teoh <hsteoh quickfur.ath.cx> writes:
On Thursday, 28 May 2020 at 19:08:18 UTC, Joseph Rushton Wakeling 
wrote:
 On Thursday, 28 May 2020 at 18:09:51 UTC, Stefan Koch wrote:
 I am all for nonothrow and nononothrow (which does not allow 
 asserts :))
nonononononotheresnolimits ;-)
In the context of DIP 1028, I really want an attribute called nojustno that I can put at the top of my source file to make extern(C) declarations system by default. ;-)
May 28
prev sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Thursday, 28 May 2020 at 16:47:01 UTC, Steven Schveighoffer 
wrote:
 On 5/28/20 12:39 PM, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer 
 wrote:
 2. If we went to an "inferred-by-default" regime, there would 
 have to be a way to opt-out of it, to allow for crafting 
 attributes of public extern functions.
You'd just have to write them out there.
Not possible in some cases ( throws, gc, impure)
 
 4. Documentation should show the inferred attributes IMO (not 
 sure if this already happens for auto functions for example).
Eeeeeeh, I'd be ok with that but it would need to actually point out that it was inferred - that this is NOT a promise of forward compatibility, it just happens to be so in this version
Sure, that's a reasonable expectation. -steve
I'm a fan of your auto-inference or inferred-by-default or whatever you'd like to call it ideas. Wider utility and less "annotation soup". If you've got the time, I'd suggest your starting a new thread. Now that Walter has withdrawn 1028 we could really use something to amp up safe, and other attribute, utility.
May 28
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 28 May 2020 16:39:21 +0000 schrieb Adam D. Ruppe:

 On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer wrote:
 2. If we went to an "inferred-by-default" regime, there would have to
 be a way to opt-out of it, to allow for crafting attributes of public
 extern functions.
You'd just have to write them out there.
I haven't though about it a lot, but I think I'd prefer to have stable library ABIs by default. So at least all export-ed, non-templated functions should not have inference. Otherwise we'd have to add a best-practice 'fully annotate all exported function to avoid ABI breakage' rule, which then again is some sort of programming by convention... -- Johannes
May 28
parent Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 29 May 2020 at 06:26:29 UTC, Johannes Pfau wrote:
 Am Thu, 28 May 2020 16:39:21 +0000 schrieb Adam D. Ruppe:

 On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer 
 wrote:
 2. If we went to an "inferred-by-default" regime, there would 
 have to be a way to opt-out of it, to allow for crafting 
 attributes of public extern functions.
You'd just have to write them out there.
I haven't though about it a lot, but I think I'd prefer to have stable library ABIs by default. So at least all export-ed, non-templated functions should not have inference. Otherwise we'd have to add a best-practice 'fully annotate all exported function to avoid ABI breakage' rule, which then again is some sort of programming by convention...
Unless it's believed that the separate compilation capability is both essential and plausibly intractable, experimenting with the "I have all the source code" subset first seems like a good idea. For one, I'm pretty sure that we can find a way to store/retrieve compiler inferences.
May 28
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/28/20 11:12 AM, Steven Schveighoffer wrote:
 On 5/28/20 10:53 AM, Joseph Rushton Wakeling wrote:
 On Thursday, 28 May 2020 at 13:53:39 UTC, Adam D. Ruppe wrote:
 The beauty of inferred by default is neither are breaking changes.
Not sure I agree about that TBH.  Inferred-by-default just means the function signature doesn't by default tell you anything about what properties you can rely on, and any change to the implementation may alter the available properties, without any external sign that this has happened.
1. Templates already do this, and it has not been a problem (much of Phobos and much of what I've written is generally templates). 2. If we went to an "inferred-by-default" regime, there would have to be a way to opt-out of it, to allow for crafting attributes of public extern functions. 3. You would still need to specify exact attributes for virtual functions. 4. Documentation should show the inferred attributes IMO (not sure if this already happens for auto functions for example). 5. Yes, inferred attributes might change. This would be a breaking change. It might be a breaking change for others where it is not for the library/function in question. But it would still be something that IMO would require a deprecation period. For things outside our control, it's very possible that these changes would be done anyway even if they were actual attributes. 6. One might also take the view that a lack of attributes means the function may or may not have those attributes inferred in the future (i.e. it's not part of the API). I think much code is already written this way.
Large projects separate compilation inter-procedural analysis does not scale yadda yadda yadda.
May 28
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu 
wrote:
 Large projects separate compilation inter-procedural analysis 
 does not scale yadda yadda yadda.
We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....
May 28
next sibling parent Johannes Pfau <nospam example.com> writes:
Am Thu, 28 May 2020 23:35:48 +0000 schrieb Adam D. Ruppe:

 On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu wrote:
 Large projects separate compilation inter-procedural analysis does not
 scale yadda yadda yadda.
We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....
Unfortunately what really limits us here is the C/C++ toolchain ecosystem (linker, library loader...). Ideally we'd do an attribute inference / code generation / inline information generation (function 'classification') pass exactly once per module, then store the information in some sort of compiled intermediary file. For (cross-module) inlining, this is essentially what LTO does. But I don't know whether you could include enough other information, such as function prototypes for all analyzed functions... Maybe it'd make sense to store this information to separate files, but then it's more difficult again to integrate into current toolflows. -- Johannes
May 28
prev sibling next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 28 May 2020 at 23:35:48 UTC, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu 
 wrote:
 Large projects separate compilation inter-procedural analysis 
 does not scale yadda yadda yadda.
We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....
It's not surprising that copying a CompoundStatement all over the place and then discarding most of it is a waste.
May 29
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/28/20 7:35 PM, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu wrote:
 Large projects separate compilation inter-procedural analysis does not 
 scale yadda yadda yadda.
We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....
Needs to be based in sound analysis, not measurements, as a quadratic is not scalable regardless of the constant. When I was in the field there was no escaping this fact, and all interprocedural analyses that did anything interesting were limited to programs a few KB in size. Perhaps things have improved since, and it would be great if they did. Timon should know about this.
May 29
next sibling parent Arun Chandrasekaran <aruncxy gmail.com> writes:
On Friday, 29 May 2020 at 12:52:06 UTC, Andrei Alexandrescu wrote:
 On 5/28/20 7:35 PM, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu 
 wrote:
 Large projects separate compilation inter-procedural analysis 
 does not scale yadda yadda yadda.
We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....
Needs to be based in sound analysis, not measurements, as a quadratic is not scalable regardless of the constant. When I was in the field there was no escaping this fact, and all interprocedural analyses that did anything interesting were limited to programs a few KB in size. Perhaps things have improved since, and it would be great if they did. Timon should know about this.
Where I work we typically use decision matrix. In it's current state, DIP process would benefit if a decision matrix can be introduced for controversial proposals. It will help to summarize the options and counter options proposed and the weightage for each option (based on sound reasoning). https://en.wikipedia.org/wiki/Decision_matrix
May 29
prev sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 29 May 2020 at 12:52:06 UTC, Andrei Alexandrescu wrote:
 On 5/28/20 7:35 PM, Adam D. Ruppe wrote:
 On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu 
 wrote:
 Large projects separate compilation inter-procedural analysis 
 does not scale yadda yadda yadda.
We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....
Needs to be based in sound analysis, not measurements, as a quadratic is not scalable regardless of the constant. When I was in the field there was no escaping this fact, and all interprocedural analyses that did anything interesting were limited to programs a few KB in size. Perhaps things have improved since, and it would be great if they did. Timon should know about this.
Of course, we need both theory and the empirical. O(N lg N) may be the upper limit of what is countenanced for performance work, a useful filter, but the constants, as Andrei knows better than most, can really get you. Big-Oh is helpful but it is too loose to be the final word. Additionally, the empirical can help you catch big-Oh analysis errors.
May 29
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/28/20 9:42 AM, Joseph Rushton Wakeling wrote:
 On Wednesday, 27 May 2020 at 23:57:00 UTC, Meta wrote:
 What's wrong with nothrow by default? Probably 97% of code doesn't 
 need to throw exceptions.
One point of view can be to consider the consequences of fixing code that incorrectly uses the default. If we have throws-by-default, then marking an existing non-templated method ` nothrow` is not a breaking change. If we have nothrow-by-default, then marking an existing non-templated method ` throws` is a breaking change. Another point of view could be that there's a benefit to being permissive by default in terms of what the developer can do.
And that should be a breaking change. So all is good. Changing the regime of a function from nothrow to throw is major. I'm sympathetic with making functions nothrow the default. The reader and compiler taking into account the possibility of throwing is a large upfront tax. That should not be paid without necessity.
May 28
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 28 May 2020 at 22:43:29 UTC, Andrei Alexandrescu 
wrote:
 And that should be a breaking change. So all is good.

 Changing the regime of a function from nothrow to throw is 
 major.
Of course changing the regime of a function from nothrow to throw is major. That will be the case whatever the default regime is. But the point I was making was about how default regime choice mixes with the requirement for breaking change. The scenario imagined here is "What happens if a function is using the default regime by accident because the developer forgot to add an attribute to change it?" If the default regime is 'throw', then one can switch a function from the default regime to its opposite, without breaking change. If the default regime is 'nothrow', then changing from the default regime to its opposite is inherently a breaking change. We can reasonably expect that it will be a common scenario for developers to just use the default and then realize later that wasn't intended. So when picking a default regime, it might be a good idea to pick the default that allows switching away without breakage. (The same argument has been advanced for final-by-default class methods, you may recall.)
May 30
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu 
wrote:
(...)
 If this is greenwashing, then DIP 1028 is doing it.
Using the greenwashing phrase against Walter's case for DIP 1028 is a good rhetoric, but a weak argument and does little good I believe to further this conversation. At least you did bring a definition into the mix, almost everyone else seems to have misunderstood what greenwashing even means! It's exactly Walter's argument that *not* marking external declarations as safe by the compiler will lead to greenwashing by humans in practice, some programmer (not compiler!) putting safe declaration there to shut up the compiler. This act cannot be easily distinguished from careful analysis, thus misleading others about the memory safety of the codebase. The compiler simply follows the rules without agenda, but a human has more complex intentions. Thus, there is a very big difference is something has been 'calculated' or 'created'. And anyone reading the code who is up to date about the rules will make that difference. This is a matter of coder psychology, not language lawyers. At least this is how I understand Walters argument. The way that DIP 1028 would mislead coders about memory safety of the codebase is quite different. I think it boils down to 2 kinds of deception: 1. safe is a sham: you'd expect safe to only allow mechanically verifiably code to get compiled but it doesn't. This is a PR problem. It's the same as pure, you'd expect it to verify the referential integrity of a function, but it actually doesn't. If seen people invent to word 'weak purity' and 'strong purity' to cope with it. In practice, it's not really a problem but the PR around it is not nice. 2. relaxing safe to allow unannotated externs will make it less useful, because in order to assess the memory safety in a reasonable way every part of the codebase, dependency and all transitive dependencies will need to be (manually) checked for unannotated externs, and this needs to be done every time you update your dependencies. Only 1 could be thought of as greenwashing. I don't feel that's particularly convincing, but it also depends how safe-by-default is presented. There should be a huge caveat that it only applies to code the compiler can verify, and any unannotated code external to the compiler is assumed to be safe as well. As for 2: for a lot of cases it will only be reasonable if the whole codebase including transitive dependencies can be mechanically checked on the usage of unannotated externs. Those should be banned in a quality check. I know Walter hates warnings and thinks it should be in a linter, but this might be something the compiler could warn for and optionally treat as an error. The warning would also combat the false impression of wholesale greenwashing with a big 'told you so'.
May 27