On 2013-01-25 16:16, mist wrote:

> Good. Main questions remain though: is property syntax allowed on
> extension methods? Is WordCount(s) call allowed?

I'm not particular familiar with this, perhaps someone else can answer these questions.

-- 
/Jacob Carlborg

On 2013-01-25 18:12, Adam Wilson wrote:

>> @property(get, set) int a;
>> @property(get) int b;
>> @property(set) int c;
>> @property int d; // same as "a"
>>
>
> This, for the love of all that is good in the world, a million times this!

I think this syntax feels quite obvious.

-- 
/Jacob Carlborg

On 1/25/13 3:18 PM, Rob T wrote:
> On Friday, 25 January 2013 at 20:10:01 UTC, Nick Sabalausky wrote:
>> What really got me upset about it was that here we have one of my
>> favorite modern language features, properties, and then all of a sudden
>> *both* the top #1 and #2 people behind D start trying to gut it if not
>> outright remove it from the language entirely, instead of enacting, or
>> at least promising to *eventually* enact, the long overdue fixes I've
>> been anxiously awaiting.
>
> If I correctly understand Walters proposal and Andrei's view point,
> neither are proposing to fully axe property-like behavior. I stand to be
> corrected, but they both seem to think that enforcement through
> @property is not required, and that's the main point being put on the
> chopping block.
>
> Walter and Andrei may want to clarify since I cannot speak for them.

That's right with the amendment that we're looking for a solution, not pushing one. Even the title of the thread is a question.

Clearly properties are good to have. In an ideal world we wouldn't need a keyword for them and we'd have some simple rules for determining property status (especially when it comes to writes). If syntactic help is necessary, so be it. We want to make the language better, not worse.


Andrei

Here are my two cents:

First, about optional parentheses:

Optional parentheses = ambiguity.

int foo() { return 4; }
auto x = foo; // gives 4 or gives function foo?

It seems to me any ambiguity should be an error. However… it only matters when the type system can't provide the missing detail, as above.

The ambiguity may be resolved either in the function signature or at the call site. @property partly helps resolve it at the function signature, but it is a different issue from optional parentheses.

Ambiguity can also be resolved at the call site instead of the function signature. It needs to be as clear and concise as possible in addition to being unambiguous. D's method of disambiguating cases often uses the keyword "cast". Applying it in this case would lead to "cast(function)" or "cast(delegate)" to indicate the function and not the return value, where the default is to indicate the return value.

int foo() { return 4; }
int function() goo() { return foo; }

auto doh = foo(); // gives 4
auto go = foo; // Error: can't deduce type of expression foo
auto fun = cast(function) foo; // gives foo

auto ae = goo; // Error: can't deduce type (either goo or function int() foo )
auto fe = goo(); // Error: can't deduce type (either foo or 4)
auto ga = goo()(); // gives 4
auto gu = cast(function) (goo()); // gives foo
auto gi = cast(function) goo; // gives goo

This solution is unambiguous and clear, but unfortunately not very concise. In fact, "cast(function) foo" is rather a long way of saying "&foo", but much clearer and possibly safer. The type system can probably resolve most of these ambiguities anyway, which would mean the cast wouldn't appear very often, but I'm not sure.

I have no real opinion about @property. Ideally the compiler could deduce what is and isn't a property without the ugly @property attached to all the signatures, but it might invite so many abuses of this process that it's not worth it.

On Friday, 25 January 2013 at 21:20:33 UTC, Andrei Alexandrescu wrote:
> On 1/25/13 3:18 PM, Rob T wrote:
>> On Friday, 25 January 2013 at 20:10:01 UTC, Nick Sabalausky wrote:
>>> What really got me upset about it was that here we have one of my
>>> favorite modern language features, properties, and then all of a sudden
>>> *both* the top #1 and #2 people behind D start trying to gut it if not
>>> outright remove it from the language entirely, instead of enacting, or
>>> at least promising to *eventually* enact, the long overdue fixes I've
>>> been anxiously awaiting.
>>
>> If I correctly understand Walters proposal and Andrei's view point,
>> neither are proposing to fully axe property-like behavior. I stand to be
>> corrected, but they both seem to think that enforcement through
>> @property is not required, and that's the main point being put on the
>> chopping block.
>>
>> Walter and Andrei may want to clarify since I cannot speak for them.
>
> That's right with the amendment that we're looking for a solution, not pushing one. Even the title of the thread is a question.
>
> Clearly properties are good to have. In an ideal world we wouldn't need a keyword for them and we'd have some simple rules for determining property status (especially when it comes to writes). If syntactic help is necessary, so be it. We want to make the language better, not worse.
>
>
> Andrei

OK, understood. I started a discussion in wiki showing how property-like behaviour without full variable emulation can work unambiguously for a few of the edge cases, such as reference returns and taking the addresses, eg, &prop.

http://wiki.dlang.org/Talk:Property_Discussion_Wrap-up#ref_returns_and_taking_the_address

If we try and fully emulate variables, a ton of complexity starts to creep in. If we do not fully emulate variables, then it significantly weakens the arguments in favor of using @property as a means to emulate variable.

--rt

2 cents regarding your position on "@property" usage in phobos:

1) You can always use shorter syntax:
@property:
int func1();
int func2();
...

2) D is not scripting language (primarily) and as such should value issues related to long-term large code base support more than saving some typing in declaration. It is slightly similar to strong vs weak typing.

That is not gonna convince you but I hope this will be taken into consideration somehow.

On 01/25/2013 10:44 PM, Zach the Mystic wrote:
> Here are my two cents:
>
> First, about optional parentheses:
>
> Optional parentheses = ambiguity.
> ...

No, you can definitely have ambiguity without optional parentheses.
Unless that is supposed to be a destructive update. Is your statement ambiguous?


> int foo() { return 4; }
> auto x = foo; // gives 4 or gives function foo?
>
> It seems to me any ambiguity should be an error. However… it only
> matters when the type system can't provide the missing detail, as above.
> ...

That is not ambiguous.

On Friday, 25 January 2013 at 21:51:14 UTC, mist wrote:
> 2 cents regarding your position on "@property" usage in phobos:
>
> 1) You can always use shorter syntax:
> @property:
> int func1();
> int func2();
> ...
>

This already works

@property {
   int func1();
   int func2();
}

--rt

On Friday, January 25, 2013 14:59:58 Andrei Alexandrescu wrote:
> 2. I have tried to add @property appropriately in Phobos, in particular for ranges:
> 
> struct SomeRange {
> @property bool empty();
> @property ref T front();
> void popFront();
> }
> 
> There's more "@property" to be seen with "save" and "back". Subjectively that just didn't work well for me. It adds clutter to an otherwise simple and straightforward API, and penalizes usage for benefits that I could never reap. I understand how some people are glad to put that in everywhere, and find meaning in requiring parens with popFront and popBack but not the others. Yet for me it was liberating (see 1 above too) I could just write "r.popFront" without the parens and have it do its deed. It is the right semantics for a simple syntax.

That's simply a question of being able to make function calls without parens. That's different from the question of properties, much as there may be syntactic similarities.

While properties do involve not using parens, there's a lot more to them than simply not using parens. A property function is fundamentally different from a normal function by its very nature, not just by its call syntax. A property is an abstraction for a variable (and therefore should be swappable with a variable), whereas a function is explicitly an action. So, regardless of what we do with parenless function calls, getting rid of explicit properties will have serious side effects.

> 5. This is a matter in which reasonable people may disagree. For better or worse Walter and to a lesser extent myself are in the position to decide. We're doing the best to gather, mind, and integrate opinions and suggestions but clearly no decision that would please everyone. So please bear with us. I understand this may be frustrating but the best we all can do is think beyond our own preference and on behalf of the larger community.

If we throw away @property, then it will be impossible to swap between using variables and property functions, which is one of the main purposes of properties. For instance, it should be possible for a range's front to be variable if that range doesn't need a function for it. There are currently implementation problems with @property which prevent us from being able to do that with @property, but they can be fixed. However, without explicit properties of some kind, it's just not possible. Not only are the semantics of a property function still too different from a variable (e.g. += doesn't yet work with a property function), but the issue of parens on property functions is a problem.

We need to able to make it so that it's illegal to use parens on a property function, not only so that you could potentially swap it out for a public variable if the function was no longer needed but more importantly so that generic APIs (such as ranges) can guarantee that using a variable instead of a property function will work (e.g. if you can call front with parens, then front can never be an actual variable). And for that, you need explicit properties, not just the syntactic sugar of being allowed to drop parens.

Also, too much of this discussion has focused on getters. @property also has a large impact with setter properties. Without it, you'll be able to do stuff like

range.popFrontN = 7;
"hello".icmp = "world";
"/usr/bin".buildPath = "dmd";

which makes no sense. As long as we have explicit properties, we can restrict the setter syntax to functions that are actually properties and could conceivably be replaced with variables. Without them, arbitrary functions could be set as if they were variables, many (most?) of which would make absolutely no sense as variables under any circumstances.

Keeping parenless functions is one thing, but getting rid of explicit properties is another thing altogether.

- Jonathan M Davis

On Friday, January 25, 2013 23:04:58 Rob T wrote:
> On Friday, 25 January 2013 at 21:51:14 UTC, mist wrote:
> > 2 cents regarding your position on "@property" usage in phobos:
> > 
> > 1) You can always use shorter syntax:
> > @property:
> > int func1();
> > int func2();
> > ...
> 
> This already works
> 
> @property {
> int func1();
> int func2();
> }

They both already work and have do so for ages.

- Jonathan M Davis