January 25, 2013
Also I need to remind you that we break code all the time with big fixes, literally every release. And end user does not care how reasonable breaking it is, they are all the same: time needed to update the code base.

We need to admit that breaking is inevitable and go forward from there to fix real solvable problems.
January 25, 2013
On 2013-01-25 03:11, Jonathan M Davis wrote:
> On Thursday, January 24, 2013 21:01:33 Andrei Alexandrescu wrote:
>> Interesting, so that would mean if anyone ever wants to get the delegate
>> AND call it in one shot would need to write: foo()().
>>
>> I think this proposal has merit.
>
> I believe that that's what we have now.

Yes, that's the way it's always been since the D1 days.

-- 
/Jacob Carlborg
January 25, 2013
On Friday, 25 January 2013 at 05:35:19 UTC, kenji hara wrote:
> module abc;
> @property int foo(int n);
>
> void main() {
>   foo = 1;  // top-level property setter
>   1.foo;  // property getter with UFCS
> }
>
> We cannot distinguish the two usages without adding any new features.
>
> Kenji Hara

"1.foo" must be compile error here. Makes as much sense as

int a;
void main() {
    1.a;
}

Property must behave exactly like data or it is not a property.
January 25, 2013
On 01/25/13 08:39, Andrei Alexandrescu wrote:
> On 1/25/13 2:12 AM, Artur Skawina wrote:
>> On 01/24/13 21:13, Andrei Alexandrescu wrote:
>>> On 1/24/13 2:03 PM, Artur Skawina wrote:
>>>> Trying to make arguments you don't like go away and silencing the messenger is your MO.
>>>
>>> Now that's what's called "ad hominem".
>>
>> No, it's not - it's just stating the facts; this was not the first such incident.
> 
> Of course it is. The definition is simple enough, e.g. from Wikipedia: An ad hominem (Latin for "to the man"), short for argumentum ad hominem, is an argument made personally against an opponent instead of against their argument.

Hmm, I can see how you could view this as an ad hominem, given that definition,
but it's not meant to be one and actually isn't - it has no bearing on
the @property nor ()-less calls issues; this is just about the process.

Remember how you originally replied to my message, after removing everything
but one sentence, which was clearly both a summary of my subjective position
and deliberately phrased in a way to encourage at least some consideration wrt
$subject by others making a decision. This isn't a new discussion, there's no
need to restate the same arguments, from other threads, over and over again.
Your response didn't provide any counterargument nor opinion on the subject;
instead you chose to complain about the form and - I have no choice but to
assume deliberately - misinterpret it. And asked me not to 'do that', in an
attempt to manipulate the discussion.
Crying "Ad Hominem!" now, after I point out that such tactics are not really
helping to foster discussion, won't make it one, sorry.

/I/ have no problem ignoring your comments, but others may not be as thick-skinned or not view D from the same perspective, and not willing to deal with that kind of arrogance. The number of D contributors is low enough, why drive potential ones away?


>> and the choice needs to stay with the callee. But the distinction is "sane/insane"
>> for a reason - there's judgment, taste and common sense involved.
>> Trusting every programmer to get it right won't work, unfortunately.
> 
> I'd say "sane/insane" is pushing it.

Normally, I'd probably agree, but in the context of removing @property, but not implementing correct accessors nor enforcing calling syntax "insane" is appropriate. It's "sane/insane", because absolute terms such as "right/wrong" would be too strong; there is a large subjective component to it.

artur
January 25, 2013
On 2013-01-25 01:55, kenji hara wrote:
> I can imagine a situation that we might not want to treat property
> functions as DATAs simply.
>
> If you have a struct which have some property functions as members, and
> you'd want to serialize it:
>
> struct S {
>     int value_;
>     @property int value() { return value_; }
> }
>
> At least, the serialization library should recognize the S.value is a
> _property function_, not a int DATA.

A serialization library would only recognize "value_" since it's an instance variable.

-- 
/Jacob Carlborg
January 25, 2013
On Friday, 25 January 2013 at 10:26:14 UTC, Robert burner Schadek wrote:
> ...
> Yes, the syntax is legit. It's the semantic that "scares" me. IMHO it feels strange that assigning a variable resizes a array. Something like a.resize(10) would make me feel better.

Ye, it was one of the first "Erm wtf?" moments when I started to learn D. And living confirmation that core developers don't really have a strong vision what properties should be.
January 25, 2013
On Friday, 25 January 2013 at 11:00:34 UTC, Jacob Carlborg wrote:
> On 2013-01-25 01:55, kenji hara wrote:
>> I can imagine a situation that we might not want to treat property
>> functions as DATAs simply.
>>
>> If you have a struct which have some property functions as members, and
>> you'd want to serialize it:
>>
>> struct S {
>>    int value_;
>>    @property int value() { return value_; }
>> }
>>
>> At least, the serialization library should recognize the S.value is a
>> _property function_, not a int DATA.
>
> A serialization library would only recognize "value_" since it's an instance variable.

getFields/getProperties/getMethods and you are done. It don't sounds that much of a problem to me.
January 25, 2013
On Friday, 25 January 2013 at 11:01:31 UTC, mist wrote:
> On Friday, 25 January 2013 at 10:26:14 UTC, Robert burner Schadek wrote:
>> ...
>> Yes, the syntax is legit. It's the semantic that "scares" me. IMHO it feels strange that assigning a variable resizes a array. Something like a.resize(10) would make me feel better.
>
> Ye, it was one of the first "Erm wtf?" moments when I started to learn D. And living confirmation that core developers don't really have a strong vision what properties should be.

I can view *reading* size as a property, but I don't think the setter itself should be a property, since it actually *does* something. Heck, it can throw an exception (!)

However, I really think we are way past the point we can change array's interface. I'd just leave it be.
January 25, 2013
OK, it has become difficult to follow all thread (newsgroups are not that perfect for this), so I will do "tl; dr" in a form of I final proposal.

Basic statement 1: Breaking user code is inevitable
Basic statement 2: Special cases are indicators something wrong is with design
Basic statement 3: Data is not function. Function is not data. (Sorry, John von Neumann!) Property is data.

Proposal itself:
*) -property flag becomes no-op
*) parens for all callables are mandatory
*) parens for properties are prohibited
*) properties are always treated to be of type of their return data
*) As a consequence - in UFCS property always behaves as a parameter, never as function

Transition issues:
*) Before merging new behavior to master, staging is created from last backwards-compatible. Official announcement is made that it will be bug-fix supported for at least 6 months.
*) Meta bugzilla issue is created to make Phobos code more strict in this regard. Release with new behavior will be allowed to go to staging only after this issue is taken care of.
*) All property-related issues that ensure data-like behavior like "+=" are marked as preapproved.

And yes, I know that Andrei has already made his decision about optional parens and this is also a no-op. But oh well.
January 25, 2013
On 24.1.2013 23:04, Andrei Alexandrescu wrote:
> On 1/24/13 4:56 PM, Adam Wilson wrote:
>>> Simplicity is clearly good, but there's something to be said about
>>> those warts in chained calls. The UFCS-enabled idioms clearly bring a
>>> strong argument to the table, there's no ignoring it.
>>>
>>> Andrei
>>
>> Then @property needs to be fixed such that optional parens don't effect
>> it one way or the other. Removing the concept of properties and making
>> functions that look like properties through optional parens is a very
>> poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA,
>> and functions do stuff. That statement alone is an excellent argument
>> for clearly delineating which is which... Properties are not functions.
>
> I'm not all that convinced, and it's easy to get wedged into a black vs
> white position that neglects many subtleties. Properties are DATA, well
> except when you need to pass fields by reference etc. at which point the
> syntactic glue comes unglued.
>
> There's been a lot of strong positions years ago about functions vs.
> procedures, statements vs. expressions, or even (the glorious 60s!)
> in-language I/O primitives vs. I/O as library facilities. Successful
> languages managed to obviate such dichotomies.
>
>
> Andrei

Maybe this will clarify what is meant by "properties are data":


// http://dpaste.dzfl.pl/822aab11

auto foo () {
  return { return 0; };
}

@property auto bar () {
  return { return 0; };
}

void main () {
  auto localFoo = foo;
  assert(!is(typeof(localFoo) == typeof(foo)));
  auto localBar = bar;
  assert(is(typeof(localBar) == typeof(bar)));
}



function:
auto localFoo = foo; // call foo and store the result
typeof(localFoo) // typeof(data returned by foo) - function pointer
typeof(foo) // typeof(function foo) - function

data:
auto localBar = bar; // get data represented by bar
typeof(localBar) // typeof(data represented by bar) - function pointer
typeof(bar) // typeof(data represented by bar) - function pointer


Data represented by bar can be some value, or a function call that returns a value. As a user of that property I don't care. And I don't want my code to break if that property changes from a function pointer to a function that returns a function pointer. Hence typeof(foo) is a function, and typeof(bar) is a type of that property (type that is returned by a calling bar). I would like to emphasize that @property is not a syntactic, but rather a semantic issue.