On 31 March 2014 18:16, Walter Bright <[email protected]> wrote:
> On 3/31/2014 12:51 AM, Manu wrote: > >> Now it's deceptive that it's a pointer, and the pointer semantics are not >> suppressed. It might be surprising to find that a type that doesn't look >> like a >> pointer behaves like a pointer. >> You lose access to the operators, indexing/slicing etc, etc. >> I don't see how this is a reasonable comparison to 'class' as a reference >> type >> by definition. >> > > Of course it's reasonable - not many classes overload operators. > Is there a way to disable indexed dereferencing? Slicing? The point is, there are numerous solutions available, you aren't stuck with > one solution for every problem. > I just wouldn't go so far as to call these alternatives 'solution's. A pointer is a pointer. Calling it a reference type is a stretch. While it can be indexed, sliced, and operators don't work, I don't think this is a compelling solution in very many contexts, and certainly not a general solution. And, you can use 'alias this' as Adam showed to create a type with fully > customized behavior - you don't have to change the language to prove your > ideas. > I haven't made any suggestion to change the language, I just said that adam's idea (well, not necessarily his idea, it seems to be an established pattern) is a rather elaborate hack; in many cases the boilerplate exceeds the volume of the useful code. The whole pointer-to-Impl + getter property + alias this + etc pattern is quite a lot of boilerplate. It's a really common pattern, it's obviously very useful, but it's surprising to me that people think that it's like, 'cool'. I get why it's done, and it's cool that D can do this (I use it a lot in my code), but I don't feel it's particularly elegant.
