[phobos] Time to get ready for the next release

[Steve Schveighoffer]

----- Original Message -----

> From: Don Clugston <dclugston at googlemail.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Cc: 
> Sent: Wednesday, April 27, 2011 7:13 AM
> Subject: Re: [phobos] Time to get ready for the next release
> 
>G uys, you really hijacked this thread!

Sorry about that.  It's one of those things where, you don't want to leave arguments un-countered :)

I've decided to stop arguing, I'm pretty confident that things will be implemented as they are described in TDPL.

> 2. Tight semantics prevent the use of the "fluent programming" idiom 
> which is
> reasonably widely-used.

This is not true.  There is nothing in fluent programming that says the functions one defines for fluent calls must also be properties.

For example, with tight semantics, one can define a property int x, and then a method typeof(this) setX, whereby the second method can be used in fluent programming.  In fact, I've used this exact design in Tango's sys.Process.

What is not supported is using the property name to do fluent programming, however, this requires the property setter to return this, which IMO is not a design we need to cater to.  If a setter returns anything, it should return the value set (for assignment chaining, e.g. x.prop1 = x.prop2 = 5).

> 3. If we go with tight semantics, we break existing code. If we don't,
> we break TDPL.

tight semantics is guaranteed to break existing code, because it restricts what was previously not restricted.  This is no argument to not implement it.

Now, it does break existing *designs*, but those designs can be had with minor changes to the code (see my above comment).  However, expect some backlash, because people don't like to change things that work for them.

> I'm seeing a fair bit of argument AGAINST tight semantics.
> But I'm seeing pretty much no argument FOR loose semantics.
> I'm not seeing any reason to choose loose semantics over D1 semantics.

Given that those arguing against tight semantics likely don't use @property, I think they are not really concerned with the semantics of @property functions, they only care about non- at property functions.  Likely, they would not care whether @property stays or goes, just as long as it doesn't affect how they call non- at property fucntions.  Correct me if I'm wrong, guys.

-Steve