www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Can someone tell me what the compiler thought I was trying to do?

reply WhatMeWorry <kheaser gmail.com> writes:
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?
Oct 14 2022
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Oct 14, 2022 at 09:51:54PM +0000, 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
Oct 14 2022
parent reply Mike Parker <aldacron gmail.com> writes:
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.
---
Oct 14 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Sat, Oct 15, 2022 at 12:47:02AM +0000, 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.
Oct 18 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
https://github.com/dlang/dmd/blob/master/druntime/src/core/attribute.d#L292
Oct 18 2022
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
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.
Oct 18 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Oct 19, 2022 at 01:15:37AM +0000, 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.
Oct 18 2022
next sibling parent reply mw <mingwu gmail.com> writes:
On Wednesday, 19 October 2022 at 01:30:23 UTC, H. S. Teoh wrote:

 On Wed, Oct 19, 2022 at 01:15:37AM +0000, 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?
Oct 18 2022
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
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
Oct 18 2022
parent reply mw <mingwu gmail.com> writes:
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"
Oct 18 2022
parent reply Paul Backus <snarwin gmail.com> writes:
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.


added originally as a type attribute only, and later had its 
usage extended to functions.
Oct 18 2022
parent reply mw <mingwu gmail.com> writes:
  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/nmornkxaxddfziqmqqld forum.dlang.org

in general, it's about: command query separation principle
Oct 18 2022
parent reply zjh <fqbqrr 163.com> writes:
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`.
Oct 18 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
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.
Oct 18 2022
parent zjh <fqbqrr 163.com> writes:
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.
Oct 18 2022
prev sibling parent zjh <fqbqrr 163.com> writes:
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.
Oct 18 2022
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
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 +0000, 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
Oct 18 2022
parent Mike Parker <aldacron gmail.com> writes:
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.
Oct 18 2022
prev sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 19/10/2022 2:30 PM, H. S. Teoh wrote:

 On Wed, Oct 19, 2022 at 01:15:37AM +0000, 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 )
Oct 18 2022
prev sibling parent Mike Parker <aldacron gmail.com> writes:
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!
Oct 14 2022