Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 05:41:26 UTC, zjh wrote: Why always afraid to `add features`? C++ is `so complicated` ,but that people are not afraid to continue to `add features`. Look at the `emerging` languages, which are not crazy about `adding features`. Even `go` is adding generics.
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 05:50:18 UTC, zjh wrote: In my opinion, as long as `users` have reasonable needs, languages should added corresponding features, instead of becoming religions. `Some features` are very popular for users,I really don't know why they didn't add it. When you show `prejudice`, users are lost. Like `class`, when it can be used as the smallest `encapsulation unit`, it can provide `this feature` but intentionally does not. Just like when you ride a bicycle, but it has a `square` tire.
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 05:41:26 UTC, zjh wrote: Why can't do it `in one step`? Why always afraid to `add features`? C++ is `so complicated` ,but that people are not afraid to continue to `add features`. There is also `class level private`. I saw someone start it by himself, and he felt very happy. It completely conforms to the encapsulation, but it seems that the latest D has no switch about it. In my opinion, as long as `users` have reasonable needs, languages should added corresponding features, instead of becoming religions. `Some features` are very popular for users,I really don't know why they didn't add it.
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 04:59:40 UTC, mw wrote: ... Why can't do it `in one step`? Why always afraid to `add features`? C++ is `so complicated` ,but that people are not afraid to continue to `add features`.
Re: Can someone tell me what the compiler thought I was trying to do?
@mustuse as a function attribute was in the original version of the DIP. It was vetoed by Walter. Thus, only the type attribute remains in the accepted version. Let's continue the discussion here: https://forum.dlang.org/thread/nmornkxaxddfziqmq...@forum.dlang.org in general, it's about: command query separation principle
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 03:10:29 UTC, Mike Parker wrote: It's right there in the summary of the Final Review of the DIP that I linked above: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#final-review I meant to say the summary of the formal assessment. One of the conditions of acceptance was this one: develop rules for handling covariance and contravariance when applied to functions. Paul opted instead to do just have it apply to types for now. A future enhancement can take on extending it to functions. As he noted above, that's the approach Rust took as well.
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 01:34:54 UTC, mw wrote: On Wednesday, 19 October 2022 at 01:30:23 UTC, H. S. Teoh wrote: On Wed, Oct 19, 2022 at 01:15:37AM +, Adam D Ruppe via it only applies to types, not to functions. Wat... so what's the use of it then? So it's not possible to mark the return value of an int function @mustUse without making, in theory, *all* ints @mustUse? I must confess I'm baffled as to the purpose of this strange design. Same, can't believe it. Is there any (design) doc about this? It's right there in the summary of the Final Review of the DIP that I linked above: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#final-review
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 01:49:26 UTC, mw wrote: On Wednesday, 19 October 2022 at 01:38:27 UTC, Adam D Ruppe wrote: On Wednesday, 19 October 2022 at 01:34:54 UTC, mw wrote: Is there any (design) doc about this? scroll up, click the link from this very thread. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#design-goals-and-possible-alternatives """ Rather than make either sacrifice, this DIP proposes a design that allows both rigor and simplicity to be maintained, and reserves the possibility for a future DIP to allow @mustUse as a function attribute. """ Another future DIP? I think this DIP is flawed for not using "@mustUse as a function attribute" @mustuse as a function attribute was in the original version of the DIP. It was vetoed by Walter. Thus, only the type attribute remains in the accepted version. FWIW, this is the same path that #[must_use] took in Rust. It was added originally as a type attribute only, and later had its usage extended to functions.
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 01:38:27 UTC, Adam D Ruppe wrote: On Wednesday, 19 October 2022 at 01:34:54 UTC, mw wrote: Is there any (design) doc about this? scroll up, click the link from this very thread. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#design-goals-and-possible-alternatives """ Rather than make either sacrifice, this DIP proposes a design that allows both rigor and simplicity to be maintained, and reserves the possibility for a future DIP to allow @mustUse as a function attribute. """ Another future DIP? I think this DIP is flawed for not using "@mustUse as a function attribute"
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 01:34:54 UTC, mw wrote: Is there any (design) doc about this? scroll up, click the link from this very thread. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#design-goals-and-possible-alternatives
Re: Can someone tell me what the compiler thought I was trying to do?
On 19/10/2022 2:30 PM, H. S. Teoh wrote: On Wed, Oct 19, 2022 at 01:15:37AM +, Adam D Ruppe via Digitalmars-d-learn wrote: On Wednesday, 19 October 2022 at 00:57:31 UTC, H. S. Teoh wrote: Has it really been implemented? I tested the latest git master, the following code doesn't compile: it only applies to types, not to functions. Wat... so what's the use of it then? So it's not possible to mark the return value of an int function @mustUse without making, in theory, *all* ints @mustUse? I must confess I'm baffled as to the purpose of this strange design. Oh but it gets better: From C23 draft: The nodiscard attribute shall be applied to the identifier in a function declaration or to the definition of a structure, union, or enumeration type. If an attribute argument clause is present, it shall have the form: ( string-literal )
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 01:30:23 UTC, H. S. Teoh wrote: On Wed, Oct 19, 2022 at 01:15:37AM +, Adam D Ruppe via it only applies to types, not to functions. Wat... so what's the use of it then? So it's not possible to mark the return value of an int function @mustUse without making, in theory, *all* ints @mustUse? I must confess I'm baffled as to the purpose of this strange design. Same, can't believe it. Is there any (design) doc about this?
Re: Can someone tell me what the compiler thought I was trying to do?
On Wed, Oct 19, 2022 at 01:15:37AM +, Adam D Ruppe via Digitalmars-d-learn wrote: > On Wednesday, 19 October 2022 at 00:57:31 UTC, H. S. Teoh wrote: > > Has it really been implemented? I tested the latest git master, the > > following code doesn't compile: > > it only applies to types, not to functions. Wat... so what's the use of it then? So it's not possible to mark the return value of an int function @mustUse without making, in theory, *all* ints @mustUse? I must confess I'm baffled as to the purpose of this strange design. T -- Doubt is a self-fulfilling prophecy.
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 00:57:31 UTC, H. S. Teoh wrote: Has it really been implemented? I tested the latest git master, the following code doesn't compile: it only applies to types, not to functions.
Re: Can someone tell me what the compiler thought I was trying to do?
https://github.com/dlang/dmd/blob/master/druntime/src/core/attribute.d#L292
Re: Can someone tell me what the compiler thought I was trying to do?
On Sat, Oct 15, 2022 at 12:47:02AM +, Mike Parker via Digitalmars-d-learn
wrote:
> On Friday, 14 October 2022 at 22:17:52 UTC, H. S. Teoh wrote:
>
> > Given that this particular trap crops up regularly, perhaps some
> > sort of warning ought to be added. Once the @nodiscard DIP is
> > accepted & implemented this should be easy to do.
> >
>
> Seems like you're behind the times! The DIP was accepted and implemented
> with some changes:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#final-review
Has it really been implemented? I tested the latest git master, the
following code doesn't compile:
--
@mustUse int fun() { return 455; }
void main() {
fun();
}
--
Compiler output:
--
/tmp/test.d(1): Error: undefined identifier `mustUse`
--
I tried @mustuse, @nodiscard, @noDiscard, no good. What am I missing?
T
--
This is not a sentence.
Re: Can someone tell me what the compiler thought I was trying to do?
On Friday, 14 October 2022 at 22:17:52 UTC, H. S. Teoh wrote: Given that this particular trap crops up regularly, perhaps some sort of warning ought to be added. Once the @nodiscard DIP is accepted & implemented this should be easy to do. Seems like you're behind the times! The DIP was accepted and implemented with some changes: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#final-review The summary in full: --- The language maintainers accepted this DIP with a request for changes: * rename `@noDiscard`, as they want to avoid adding additional negative attributes to the language. * address issues that arise from the feature's interaction with inheritance when applied to classes. * develop rules for handling covariance and contravariance when applied to functions. The DIP author addressed these requests by renaming the attribute to @mustuse and allowing it only on structs and unions. His rationale for the latter is described in the section, Design Goals and Possible Alternatives. The maintainers approved the author's changes and accepted the revised version of the DIP. ---
Re: Can someone tell me what the compiler thought I was trying to do?
On Friday, 14 October 2022 at 21:51:54 UTC, WhatMeWorry wrote: I lost about a half an hour troubleshooting some code of mine which as it turned out to be resolved with just one line. // paths.remove(i); // compiles fine but does nothing paths = paths.remove(i); // works - what I erroneously thought the previous line was doing Is the first line nonsensical and should the compiler have at least issued a warning? At the moment, no. You should have read the documentation of the function :-) Note that remove does not change the length of the original range directly; instead, it returns the shortened range. If its return value is not assigned to the original range, the original range will retain its original length, though its contents will have changed: You ignored the return value of a function you shouldn't have ignored. It's not practical for the compiler to warn every time you do that, as it currently can't know that you're *supposed* to use it. `@mustuse` was added to the language in 2.100.0 as an attribute for `struct` or `union`, but not yet for functions, as explained in the DIP: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#mustuse-as-a-function-attribute If that ever gets expanded for use as a function attribute, then it can be used in situations like this so that you must use the return result. Until then, read the documentation!
Re: Can someone tell me what the compiler thought I was trying to do?
On Fri, Oct 14, 2022 at 09:51:54PM +, WhatMeWorry via Digitalmars-d-learn wrote: > > I lost about a half an hour troubleshooting some code of mine which as it > turned out to be resolved with just one line. > > > // paths.remove(i); // compiles fine but does nothing > > paths = paths.remove(i); // works - what I erroneously thought the previous > line was doing > > Is the first line nonsensical and should the compiler have at least > issued a warning? Depending on what your range type was, it may not necessarily do *nothing* (it may mutate the range). But as Andrei put it, "range mutation functions change content, not topology". It *returns* the new "topology", i.e., the new range after the removal; so you need to assign it to the original range in order to keep it up-to-date. Given that this particular trap crops up regularly, perhaps some sort of warning ought to be added. Once the @nodiscard DIP is accepted & implemented this should be easy to do. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
