On Tuesday, February 05, 2013 21:22:34 Andrei Alexandrescu wrote:
> Note that most people tend to vastly overestimate their few first language designs, and that there are much more people who think are good at language design than those actually are. (Note I'm only passing opinion on what I saw; You may as well be an awesome language designer, but the spark is not visible in this particular proposal.) Though I've had an idea or two that stuck, I confess without any false modesty that I don't consider myself to be a noted language designer.

Another thing to consider is that it's fairly common for people to come up with ideas that seem like very good ideas and seem very solid but which ultimately end up falling apart due to corner cases. And we're already suffering from features which are partially implemented and not necessarily fully thought through, even if they're solid in their basics.

As far as changing D goes, we're far enough along in the process that anything which would break backwards compatibility needs a really compelling case for it happen. We're trying to stabilize the language, which _does_ require breaking code in some cases, but we'd like to minimize that. Backwards compatible feature requests are more likely to make it in, but even then, they need very compelling use cases and are likely to be held back by all of the work that _needs_ to be done (new features may be nice, but they're unlikely to be necessary at this point). We're past the point where we're freely mucking with the language to try out new ideas but instead are trying to polish what we have.

But as Andrei says, there's tons of room for stuff to be done on the library front and plenty of work to do helping out with stuff like documentation and articles. So, there's tons for people to do to help out, and there's certainly plenty of innovation that could be done with regards to how stuff is handled in new stuff in the standard library. It's just the lanugage itself where we're limiting what innovation we put into it at this point.

- Jonathan M Davis

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.

On Wednesday, 6 February 2013 at 02:36:13 UTC, Jonathan M Davis wrote:
> On Tuesday, February 05, 2013 21:22:34 Andrei Alexandrescu wrote:
>> Note that most people tend to vastly overestimate their few first
>> language designs, and that there are much more people who think are good
>> at language design than those actually are. (Note I'm only passing
>> opinion on what I saw; You may as well be an awesome language designer,
>> but the spark is not visible in this particular proposal.) Though I've
>> had an idea or two that stuck, I confess without any false modesty that
>> I don't consider myself to be a noted language designer.
>
> Another thing to consider is that it's fairly common for people to come up
> with ideas that seem like very good ideas and seem very solid but which
> ultimately end up falling apart due to corner cases. And we're already
> suffering from features which are partially implemented and not necessarily
> fully thought through, even if they're solid in their basics.
>
> As far as changing D goes, we're far enough along in the process that anything
> which would break backwards compatibility needs a really compelling case for
> it happen. We're trying to stabilize the language, which _does_ require
> breaking code in some cases, but we'd like to minimize that. Backwards
> compatible feature requests are more likely to make it in, but even then, they
> need very compelling use cases and are likely to be held back by all of the
> work that _needs_ to be done (new features may be nice, but they're unlikely
> to be necessary at this point). We're past the point where we're freely
> mucking with the language to try out new ideas but instead are trying to
> polish what we have.
>
> But as Andrei says, there's tons of room for stuff to be done on the library
> front and plenty of work to do helping out with stuff like documentation and
> articles. So, there's tons for people to do to help out, and there's certainly
> plenty of innovation that could be done with regards to how stuff is handled in
> new stuff in the standard library. It's just the lanugage itself where we're
> limiting what innovation we put into it at this point.
>
> - Jonathan M Davis

Well, Jonathan M Davis, I had posted a second response to Andrei's first comment before reading either his second one or yours. But I think I pretty much explained my position, for better or worse. It's not so much not having the feature included so much as wanting to know why because despite Andrei's clear intelligence and good intentions, I felt pretty strongly that I had put onto the table something very good.

It is not feature creep, it is properties done right. If not done this way, than honestly I don't know what properties are good for any way. We could use set/get methods just as well.

If properties done right are feature creep, than properties per se are feature creep, which is debatable. But if we keep them, we should do them right.

Maybe you can elaborate what properties are good for, if not for avoiding trivial set/get methods? -> Please really do that, because I am having a hard time understanding your reasoning.



On Tue, 2013-02-05 at 08:31 -0500, Andrei Alexandrescu wrote:
> The problem with this approach is feature creep - there will always
> be
> yet another possible case in which a feature helps some case. We need
> to
> put a halt on that.

On Wednesday, 6 February 2013 at 01:40:37 UTC, Andrej Mitrovic wrote:
> On 2/6/13, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>> That's why some of us have suggested
>> making it so that you can mark variables with @property.
>
> What Jonathan means is this:
>
> struct S
> {
>     int var;  // modifiable, can take address
> }
>
> Now suppose later you want to turn var into a property:
>
> struct S
> {
>     @property int var();
>     @property void var(int);
> }
>
> This potentially breaks code if the user-code was using a pointer to
> the public var field in the previous version of your library.
>
> So instead we should have the ability to annotate fields with @property:
>
> struct S
> {
>     @property int var;  // modifiable, can *not* take address
> }
>
> There's no run-time cost, but it disallows taking the address of var,
> and it allows you to introduce property functions in the future
> without breaking user-code.

It is also possible to first start with setters/getters and then switch to a public field(!)

Which leads to the conclusion, in order for the property abstraction to be complete, address taking of *anything* annotated with @property should either NOT be allowed...

@property int var();     // can *not* take address
@property void var(int); // can *not* take address
@property int var;       // can *not* take address

... or we have to guarantee that the type remains unchanged... which is problematic due to different types of the getter and setter, which would force one to always specify the expected type rather than relying on auto.

@property int var;
int  delegate()    d_get = &var;
void delegate(int) d_set = &var;

On 02/03/2013 09:16 AM, Andrei Alexandrescu wrote:
> Walter and I have had a discussion on how to finalize properties.
>
> http://wiki.dlang.org/DIP23
>
Could someone summarize the curent state and update the wiki pages accordingly.
If the discussion has settled can we bless one of the 3 property DIPs with being approved?
Otherwise what work has to be done to get there?

http://wiki.dlang.org/DIP21
http://wiki.dlang.org/DIP23
http://wiki.dlang.org/DIP24