Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted

2022-01-28 Thread Bruce Carneal via Digitalmars-d-announce

Well done Paul.  I appreciate the clarity, simplicity and utility.




Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted

2022-01-28 Thread M.M. via Digitalmars-d-announce

On Friday, 28 January 2022 at 13:07:13 UTC, Mike Parker wrote:
Congratulations to Paul Backus. DIP 1038, "@mustUse" has been 
accepted after he implemented changes to address concerns from 
Walter.


https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md
...



Congratulations! (And thank you everyone involved in the 
discussions and feedback.)


Re: The DIID series (Do It In D)

2022-01-28 Thread Ola Fosheim Grøstad via Digitalmars-d-announce

On Friday, 28 January 2022 at 13:27:33 UTC, WebFreak001 wrote:
If there are people that would get upset from removing it, it's 
something that shouldn't be removed. (as there are people who 
are still interested in the project and might still use it)


I hear what you are saying, but maybe there is value in some of 
those abandoned projects for people who want to get ideas, so who 
am I to judge? I can only judge what I would look for…


One thing I like about the micro-examples approach that p0nce has 
taken is that they can be automatically tested against the latest 
compiler, so that makes the whole "outdated" question objective. 
:-)




Re: The DIID series (Do It In D)

2022-01-28 Thread WebFreak001 via Digitalmars-d-announce
On Thursday, 27 January 2022 at 23:56:55 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 27 January 2022 at 08:52:32 UTC, WebFreak001 wrote:
the list is being maintained, feel free to open PRs to update 
links and remove old stuff.


It is probably better that the current maintainers remove 
stuff, I think people would get upset if someone else started 
to wipe out projects that haven’t recieved updates in a year or 
that are just not ready for consumption.


I don't think that's the case - just open a PR removing old 
stuff, the maintainers will check that the links are indeed old 
and no longer necessary or they will tell you that it's kept 
because of reason XYZ.


If there are people that would get upset from removing it, it's 
something that shouldn't be removed. (as there are people who are 
still interested in the project and might still use it)


DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted

2022-01-28 Thread Mike Parker via Digitalmars-d-announce
Congratulations to Paul Backus. DIP 1038, "@mustUse" has been 
accepted after he implemented changes to address concerns from 
Walter.


https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md

During the Formal Assessment, Walter and Paul discussed a few 
aspects of the original proposal that Walter felt needed to be 
addressed. I will summarize them here. Please refer to the 
section of the DIP titled '[Design Goals and Possible 
Alternatives](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1038.md#design-goals-and-possible-alternatives)' for the rationale behind Paul's decisions regarding points 2 and 3 below.


The TL;DR: the attribute is now called `@mustUse` and it only 
applies to structs and unions.


1. `@noDiscard` is a negative, and though we have `nothrow` and 
`@noGC`, Walter has come to believe that negatives are suboptimal 
from a "human factors perspective". He noted that `must_use` in 
Rust is the right idea, and suggested Paul change `@noDiscard` to 
`@use`. Paul opted to go with `@mustUse` instead on the grounds 
that `@use` is too short and difficult to search for.


2. The original proposal allowed the attribute to apply to 
classes and interfaces. Walter offered examples of where it can 
cause problems when applied to classes and requested that Paul 
address these cases in the DIP. Ultimately, Paul opted to 
disallow the attribute on classes.


3. The original proposal allowed the attribute to apply to 
functions. Walter requested that Paul develop rules for 
covariance and contravariance, with would apply to function 
overloading, function overriding, function parameters, and 
implicit conversions. Ultimately, Paul opted to disallow the 
attribute on functions.


I want to reiterate that the above is only a summary. Paul and 
Walter exchanged multiple emails in discussion of these issues, 
with both proposing ideas to solve them. Paul does an excellent 
job describing his rationale for only allowing the attribute on 
structs in the [section I noted 
above](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1038.md#design-goals-and-possible-alternatives).


The final form of this DIP does not preclude future expansion of 
the feature to allow it on classes and functions. Paul has noted 
elsewhere that Rust took the similar approach in that `must_use` 
was only allowed on types initially and expanded to include 
functions later.


Anyone interested in writing a DIP for such expansion of the 
feature should certainly consult with Walter beforehand for a 
more thorough overview on what must be accounted for.