On Fri, Jan 25, 2019 at 4:00 AM Walter Bright via Digitalmars-d-announce <[email protected]> wrote: > > On 1/24/2019 11:53 PM, Nicholas Wilson wrote: > > That the conflation of pass by reference to avoid copying and mutation is > > not > > only deliberate but also mitigated by @disable. > > The first oddity about @disable is it is attached to the foo(int), not the > foo(ref int). If I wanted to know if foo(ref int) takes rvalue references,
And right here, I can see our fundamental difference of perspective... I never said anything about 'rvalue references', and I never meant anything like that; at least, not in the C++ sense, which you seem to be alluding to. In C++, rval references are syntactically distinct and identifiable as such, for the purposes of implementing move semantics. If we want to talk about "rvalue references", then we need to be having a *completely* different conversation. That said, I'm not sure why you've raised this matter, since it's not written anywhere in the DIP. What I'm talking about is "not-rvalue-references accepting rvalues", which if you want to transpose into C++ terms, is like `const T&`. > There are indeed > unlikable things about the C++ rules, but the DIP needs to pay more attention > to > how C++ does this, and justify why D differs. Particularly because D will > likely > have to have some mechanism of ABI compatibility with C++ functions that take > rvalue references. I'm not paying attention to C++ T&& rules, because this DIP has nothing to do with T&&, and there would be no allusion to connecting this to a T&& method. Again, I find that to be a very interesting topic of conversation, but it has nothing to do with this DIP. > [...] > Should `s` be promoted to an int temporary, then pass the temporary by > reference? I can find no guidance in the DIP. What if `s` is a uint (i.e. the > implicit conversion is a type paint and involves no temporary)? As per the DIP; yes, that is the point. The text you seek is written: "[...]. The user should not experience edge cases, or differences in functionality when calling fun(int x) vs fun(ref int x)." That text appears at least 2 times through the document as the stated goal. Don't accept naked ref unless you want these semantics. There is a suite of tools offered to use where this behaviour is undesirable. Naked `ref` doesn't do anything particularly interesting in the language today that's not *identical* semantically to using a pointer and adding a single '&' character at the callsite. This DIP attempts to make `ref` interesting and useful as a feature in its own right. In discussions designing this thing, I've come to appreciate the UFCS advantages as the most compelling opportunity, among all the other things that burn me almost practically every time I write D code. > The DIP should not invent its own syntax I removed it, and replaced it with simpler code (that I think is exception-correct) in my prior post here. It's also a super-trivial amendment. > It should never have gotten this far without giving a precise explanation of > how exception safety is achieved when faced with multiple parameters. I apologise. I've never used exceptions in any code I've ever written, so it's pretty easy for me to overlook that detail. Nobody else that did the community reviews flagged it, and that includes you and Andrei, as members of the community. > All that criticism aside, I'd like to see rvalue references in D. But the DIP > needs significant work. This is *NOT* an "rvalue-references" DIP; this is a "references" DIP. If you want to see an rvalue references DIP, I agree that's a completely different development, and it's also interesting to me... I had *absolutely no idea* that an rvalue-references DIP was welcome. I thought D was somewhat aggressively proud of the fact that we don't have rvalue-references... apparently I took the wrong impression. That said, this remains infinitely more important to me than an rvalue-references DIP. It's been killing me for 10 years, and I'm personally yet to feel hindered by our lack of rvalue-reference support.
