DIP23 draft: Fixing properties redux

[Zach the Mystic]

On Tuesday, 5 February 2013 at 21:59:53 UTC, Andrei Alexandrescu 
wrote:
> Just to make sure: this is about 
> http://forum.dlang.org/thread/ririagrqecshjljcdubd@forum.dlang.org.
>
> Language design is a subjective topic. With time I have learned 
> it's best to not comment very much about it. I have created 
> dozens, maybe hundreds of tidbits of language design and 
> invariably I believe they had obvious merits and negligible 
> drawbacks. The confidence in the quality of my own language 
> designs has decayed exponentially over the years.
>
> I'm telling this to put in perspective my following comment. I 
> think it's awesome that work like yours is discussed and 
> refined in this group. At the same time my opinion is that the 
> design is not appropriate for us. It changes semantics of 
> existing code

My proposal changes exactly one existing semantic, which is that 
a nested struct will find symbols it doesn't find in itself in 
the parent before looking at module and import levels. I'm pretty 
sure it's a bad practice to shadow names in nested structs, and I 
predicted no code breakage at all in the vast majority of 
projects.

> and fosters a cross-talk between subcomponents that has not 
> been time tested. It is complicated in implementation for a 
> benefit that's not properly motivated. At the top level it 
> solves the wrong problem. As stated: "The challenge is to do 
> better, both in terms of functionality and in terms of syntax, 
> than his proposal: ..." The actual challenge is to make 
> properties work with maximum backward compatibility, minimal 
> surprise, best integration with the rest of the language, and 
> maximum of benefits.
>
> Andrei

I've thought about this some more. You're right in that my 
proposal does not meet the first two design goals. But it doesn't 
harm them either. @property can exist side-by-side with my 
proposal indefinitely. The only demand you must make on 
programmers is that they convert all overloads of a given local 
property implementation at once so there's no repeat declaration. 
As far as best integration with the rest of the language, my 
proposal requires one new syntax (Highlander) and no new keyword 
or even the keeping of '@property' itself. As far as maximum of 
benefits, I think mine wins by far. Not only have properties been 
granted the full semantic power of the 
already-designed-and-implemented structs, but the features 
required to make this possible have their own uses totally apart 
from making properties easy.

Yes, my proposal fosters cross-talk between subcomponents that 
have not been time tested, but it doesn't prevent people from 
programming in the way they always have, either, with the one 
exception mentioned above.

So is my proposal properly motivated?

Here's what happened. I saw a connection between what everyone is 
trying to do with @properties and what the built-in struct 
operators already do. I can't figure out why you would want to 
have two systems when you could just design one really well 
(design goal 3 above: best integration with the rest of the 
language). So I figured out what needed to change to be able to 
use the one system for the two purposes.

The new proposal with nested structs is confusing, but I see no 
problems with it. Underneath, it's just what old-fashioned C 
programming is about, a bunch of functions which accept a bunch 
of variables, some of them references.

Whether or not my proposal gains any more traction than it 
already has, I consider myself lucky to have discovered it. It 
felt like it was just sitting right there for someone, and I was 
the one to find it. I may feel a little bad that there was so 
much opposition. So far, the original person who posed the 
challenge has said nothing at all about it, for example, but 
still, I'm glad I found it, and I don't even care at this point 
if anyone else cares.