On 23 March 2018 at 20:17, Timon Gehr via Digitalmars-d <[email protected]> wrote: > On 24.03.2018 02:16, Manu wrote: >> >> This is an interesting point, but I don't think it changes the balance >> in any way. Thinking of the majority of my anecdotal cases, I don't >> think it would be a problem. >> Something complex enough for const to be a problem likely doesn't >> conform to this pattern. > > > Why aim for "it often works", when we want "it always works"? Forcing const > upon people who want to pass rvalues by reference is just not good enough. > It is bad language design.
I think you need to re-read the whole thread, and understand what we're even talking about. Nobody wants to pass rvalues by mutable-ref... that's completely pointless, since it's an rvalue that will timeout immediately anyway. Passing by const-ref is perfectly acceptable. I suspect Jonathan's talking about classic D situations with const like, I might pass by const-ref, but then I can't call a getter that caches the result. That's a classic problem with D's const, and that's not on debate here. I don't think that has any impact on this proposal; people understand what const means in D, and that's no different here than anywhere else. > Also I think the point about documenting mutation intent is moot, as rvalues > can be receivers for method calls, which will _already_ pass an rvalue by > reference no matter whether it intends to mutate it or not. We can require > some special annotation for this behavior, but I'd be perfectly fine without > it. I have no idea what this paragraph means... can you elaborate further what you're talking about?
