On Friday, 25 January 2013 at 17:17:11 UTC, Rob T wrote:
> I think Walters proposal to shoot @property is perfectly sound. Get rid of it, fix the edge cases, and move on to solving the problems that matter a whole lot more than this one.

The reason @property exists in the first place is to fix the edge cases. It got screwed up beyond all recognition by the parenthesis debate, extending its effect well, well beyond the edge case... but that *was* why it was introduced in the first place.

On Thursday, 24 January 2013 at 22:45:52 UTC, Walter Bright wrote:
>
> Having a release process does not remove the pain of breaking changes that make users miserable because their older code no longer compiles.

What about providing a tool to automatically perform the
transform necessary to fix the code (w.r.t. the breaking change)?
That should be feasible in many cases, and there are languages
that have gone down this route already (Python 3 partially, Go
fully, if I'm not mistaken).

gath

25-Jan-2013 13:49, Don пишет:
> On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote:
>> On 1/24/2013 5:42 AM, Jacob Carlborg wrote:
>>> I agree with you but Walter is very afraid of breaking code.
>>
>> The history of what happens when D code breaks because of language
>> changes is not a happy one.
>
> I don't believe that is true. Remember when 'bit' was removed from the
> language?
> It didn't cause any complaints at all.
>
> This attitude is very harmful. Our real problem is that we're not making
> promises about what we won't change. When we haven't made such promises,
> we then become fearful of changing *anything*.
> Then we bend over backwards to avoid changing things that actually
> nobody cares about. This is a recipe for locking bugs into the language
> forever.
>
> Instead, we should be trying to continuously expand the things we
> guarantee will continue to work. Ideally we would be precise about the
> things that are likely to change, and which we don't currently guarantee.

+1

-- 
Dmitry Olshansky

On Friday, 25 January 2013 at 17:24:23 UTC, Adam D. Ruppe wrote:
> On Friday, 25 January 2013 at 17:17:11 UTC, Rob T wrote:
>> I think Walters proposal to shoot @property is perfectly sound. Get rid of it, fix the edge cases, and move on to solving the problems that matter a whole lot more than this one.
>
> The reason @property exists in the first place is to fix the edge cases. It got screwed up beyond all recognition by the parenthesis debate, extending its effect well, well beyond the edge case... but that *was* why it was introduced in the first place.

So historically, the fist implementation of the property concept was through a syntax change, allowing removal of empty parens for the getter and assignment syntax for the setter. But due to edge cases, @property was conjured up to solve them through property syntax enforcement. The syntax change was partially implemented without @property enforcement leaving it optional, and this brought on the big debate concerning enforcement of parens.

Why was a partial implementation of an experimental half-backed idea released into the wild?

In the future, we can avoid messes like this through a better design and development process with a little planning behind it. The property feature would have remained in experimental mode until most or all of the debate had been settled, then moved into beta for usage trials, and finally into a production release with no more debate and no more bugs or broken edge cases remaining.

--rt

On Friday, 25 January 2013 at 17:52:12 UTC, Dmitry Olshansky wrote:
>>
>> Instead, we should be trying to continuously expand the things we
>> guarantee will continue to work. Ideally we would be precise about the
>> things that are likely to change, and which we don't currently guarantee.
>
> +1

I agree with this completely, but we cannot do it until there's a full implementation of a reasonably designed and followed development and release process that includes the language specification.

--rt

Andrei Alexandrescu wrote:
> You made a mistake under the heat of the argument. We all do. Don't try to explain how actually you didn't. The right course is to casually apologize and move on.

At this point, the only difference between you and Nick S. is the
frequency of four-letter words in your posts.

It's a real pity, D could have been such a nice language, but
with that kind of "leadership"...

    - John

25-Jan-2013 02:32, Adam D. Ruppe пишет:
> On Thursday, 24 January 2013 at 22:28:04 UTC, Jonathan M Davis wrote:
>> However, I do think that would be able to mark variables such that
>> they're treated as rvalues such that swapping a
>> variable out with a property function dosen't break code
>

IMHO this is a critical part of what a property should do - transparently swapping fields with some functional accessors.


-- 
Dmitry Olshansky

On Friday, 25 January 2013 at 18:00:24 UTC, Rob T wrote:
> So historically, the fist implementation of the property concept was through a syntax change, allowing removal of empty parens for the getter and assignment syntax for the setter.

That was actually before my time. The optional parens feature has been in D for as long as I can remember; it was there well before 1.0.

But yeah, @property was added a few years ago over concerns about a small handful of edge cases.

> Why was a partial implementation of an experimental half-backed idea released into the wild?

This is the reason it is on a compiler switch, -property, instead of the main language. Without -property, the @property decoration is ignored. (And with -property, it doesn't do anything useful. The implementation is basically:

-property: break my code
@property: please don't break this code

It doesn't fix a single thing, and IIRC the implementor knew it; he just put it in as a first step toward something more complete.)

On Thu, Jan 24, 2013 at 12:34:42AM -0800, Walter Bright wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
> 
> Perhaps we should revert to a simple set of rules.
> 
> 1. Empty parens are optional. If there is an ambiguity with the
> return value taking (), the () go on the return value.
> 
> 2. the:
>    f = g
> rewrite to:
>    f(g)
> only happens if f is a function that only has overloads for () and
> (one argument). No variadics.
> 
> 3. Parens are required for calling delegates or function pointers.
> 
> 4. No more @property.

I've refrained so far from participating in this thread, but maybe it's time to say something.

1) @property and optional parentheses are orthogonal issues. Let's not
   conflate them and cause more unnecessary confusion in what is already
   a complex and convoluted discussion.

2) Personally, I don't like leaving out parentheses, but I don't really
   care either way. In any case, this has nothing to do with @property.

3) So, as far as @property is concerned, let's forget about optional
   parentheses or not.

3) @property is necessary for good abstraction. Yes, there have been
   precedents of abuse (like .dup and .idup, which really should *not*
   be properties but methods), and there are problems in the current
   implementation of @property, but the _concept_ of @property itself is
   a sound one. People have already mentioned the use case of a member
   variable that needs to be replaced with a getter/setter method.
   Conceptually speaking, the user of the class should not need to know
   or care whether it's just a POD field or an abstract entity
   manipulated by @property functions.

   For example, an Array class has a .length property, and user code
   should not need to know nor care if this length is an actual size_t
   field, or something else. All it needs to know is you can get a
   size_t out of it, and (optionally) change its value (if it's
   non-const, or if there's a setter method).

   Sometimes, you get into the situation where it's *possible* to
   implement a @property as a plain old field, but not desirable because
   of the SSOT (single source of truth) principle. It could be a
   computed value based on implementation-specific parameters, for
   example. It would not be nice if you had to store its value, then
   change code everywhere to make sure that it's always updated when the
   underlying parameters change. Lots of ugly, unnecessary, inefficient,
   and fragile code.

   Therefore, @property is necessary. If it causes a problem with the
   syntax, well, that's a problem with the syntax, not with the concept
   of @property itself.

As far as syntax is concerned, it should be very straightforward. Given that the goal of @property is to simulate a variable, it should syntactically be identical to a variable, regardless of what it returns. So, given:

	struct S {
		@property T prop() { ... }
	}
	S s;

Then:

a) Writing s.prop returns a value of type T, for any type T (POD or
   struct or class or delegate or whatever);
b) Writing s.prop() invokes opCall on the *return value* (because .prop
   behaves exactly as though it were an actual field);
c) As a corollary, if T is not callable, then s.prop() is illegal;
d) &s.prop returns a pointer to T (if .prop returns a ref).
e) As for taking the address of the .prop function itself, my take on it
   is that (i) from a user's POV, .prop should be indistinguishable from
   a plain old field, so you shouldn't ever need to do this, and
   therefore (ii) it's impossible, and (iii) if you *really* need to do
   it, do this instead:

	struct S {
		@property T prop() { return this.propImpl(); }

		// You really only need to know about propImpl if you're
		// inside S's implementation anyway, so this is private.
		private T propImpl() { ... }

		void someMethod() {
			auto ptr = &propImpl;
			// There, now you have it.
		}
	}

f) IOW, .prop cannot be distinguished from an actual field under normal
   circumstances. If you *really* need to do this (e.g. in serialization
   code), then use __traits.

Consequently:

- Assignment syntax like f=g should NOT be treated equivalently to f(g)
  because conceptually it makes no sense. Writing writeln = "abc"; makes
  no sense because writeln is not a value that you write to. Writing
  s.prop = "abc" *does* make sense, because S.prop is a @property, and
  therefore behaves like a variable. Writeln is a function, not a
  @property, so this is illegal.

- Syntax like s.prop++ should work automatically (equivalent to
  s.prop(s.prop+1)), if .prop has both a getter and setter @property.
  It should NOT be allowed for arbitrary methods m just because m has
  both overloads of m() and m(T).

- It's illegal to mark a function that takes 2 or more arguments as
  @property, because it makes no sense.

The bottom line is, if you mark a function as @property, then it should behave as if it were a variable of its return type. This has nothing to do with optional parentheses or not, and assignment syntax should be reserved for variables (and by extension @property, because @property means something behaves like a variable), not arbitrary functions.


T

-- 
What are you when you run out of Monet? Baroque.

On Friday, 25 January 2013 at 18:41:46 UTC, H. S. Teoh wrote:
> ...

Sound base that avoid discussion of controversial topics :) Looks like I can agree with almost everything. Probably even everything.

Only thing that needs to be defined is @property on free-functions: disallow, treat as global variable or treat as an extension methods. We has small discussion on this topic with deadalanix afair somewhere up the topic.