On 01/29/2013 09:14 AM, eles wrote:
> On Tuesday, 29 January 2013 at 13:51:05 UTC, Chad Joan wrote:
>> On 01/29/2013 06:26 AM, eles wrote:
>>> On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
>>>> to the one used for functions. That way, you can avoid verbosity and
>>>> the need to use implicit parameters
>> IIRC, C# goes like this:
>
> YRC.
>
>> property int foo
>> {
>> get
>> {
>> return m_foo;
>> }
>>
>> set
>> {
>> m_foo = value;
>> }
>> }
>>
>> C# properties have a couple disadvantages:
>> - They introduce an extra nesting level.
>> - There is a possible nonsense error if someone places code outside of
>> the get/set but inside the property scope.
>
> The compiler will scream at you. This is why it analyses the code, to
> make sure it understands it.
>

My point is that this is another error that has to be coded into the compiler.  Another error that can show up on your screen.  Generally it is a better course to make it impossible for errors to happen at all.

>> - You don't get to determine how the setter value is passed. ref? auto
>> ref? const?
>
> Frankly? Why you would care? You only write a.x=b. How it is b passed?
> It is the job of the compiler to pass b, not yours.
>

I do care.  Whether things are const or not matters a lot.  You wouldn't be able to write (foo.prop = "hi") if prop has a non-const parameter. Also, if the property type is some large struct, then I'll want to pass it as ref to avoid a huge copy overhead.

>> - They use 4 keywords, whereas we can get away with 2 probably.
>
> Yes. This is why brainfuck become no.1 language ever invented, because
> it uses very few keywords. And this is why Java never really took off,
> just because it introduces new keywords like extends and implements
> instead of our lovely :. Lovo of keywords changed the world...
>
>> - Things get uglier when you add D's function pure and const
>> annotations to it.
>
> *Everything* become uglier with that. Everything.
>
>> Semantically, they accomplish the same thing as D's properties: they
>> get lowered into two methods, one getter and one setter. There has to
>> be /some/ way to attach executable code to a symbol for this
>> properties concept to work at all.
>
> If they are the same, why they are different to the point that you love
> one but hate the other?

Semantics != Syntax

"Semantically" is a really important qualifier in formal language discussion.

On Tuesday, 29 January 2013 at 14:33:12 UTC, Chad Joan wrote:
> On 01/29/2013 09:14 AM, eles wrote:
>> On Tuesday, 29 January 2013 at 13:51:05 UTC, Chad Joan wrote:
>>> On 01/29/2013 06:26 AM, eles wrote:
>>>> On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
>>>>> to the one used for functions. That way, you can avoid verbosity and
>>>>> the need to use implicit parameters
>>> IIRC, C# goes like this:
> I do care.  Whether things are const or not matters a lot.  You wouldn't be able to write (foo.prop = "hi") if prop has a non-const parameter.

So, with the current approach, if one forgets to write the non-const parameter, will very likely end up with a property that is context-sensitive...

Surely, I have the feeling that functions are the simple thing, while properties are some new, more complicated language constructs, that were invented in order to overcome the limitations of those poor functions...

At least now we have a strong reason why properties are needed in the language: just as every C/C++ program can be reduced to a for() loop, so every D program will be reduceable to a property... It is a matter to keep up with C++ after all.

On Tuesday, 29 January 2013 at 14:33:12 UTC, Chad Joan wrote:
> On 01/29/2013 09:14 AM, eles wrote:
>> On Tuesday, 29 January 2013 at 13:51:05 UTC, Chad Joan wrote:
>>> On 01/29/2013 06:26 AM, eles wrote:
>>>> On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
>>>>> to the one used for functions. That way, you can avoid verbosity and
>>>>> the need to use implicit parameters
>>> IIRC, C# goes like this:
> Semantics != Syntax
>
> "Semantically" is a really important qualifier in formal language discussion.

Syntax is a very subjective thing (remember that writeln = "hello"?).

Concepts are important to be constructed well. I think (well, subjectively), that properties are closer, conceptually, to variables than to functions.

At least, they should be.

On 2013-01-29 15:00, eles wrote:
> well, make those parens omittableonly if the function name is
> followed by a dot.

This is a sound idea for typical cases:
typeof(foo);  // works,
x = a.chain.of.operations();  // looks good and () are informative.

Only the problem with functions returning callable objects remains:
write(foo()()); // ugly but explicit and we know what happens,
foo().write();  // is it the phobos write or a write method
                // of the object returned by foo?

On 1/29/13 6:33 AM, eles wrote:
> On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
>> need to adopt the inferior C# approach.
>
> And there is another problem with the "superior" D approach: a typing
> mistake in the name of a property might let you not with one property
> that is r/w, but with two properties to which one is r/o and the other
> is w/o.
>
> More, those functions might be placed several screens far one from the
> other.

I agree this is an issue. I think it's good language design to avoid "long-distance influence" of one declaration against another.

This is a strong argument for keeping @property for write properties.


Andrei

On Tuesday, 29 January 2013 at 00:56:41 UTC, Chad Joan wrote:
> Would everyone be able to agree to only use @property functions as properties?  This would still allow omittable parens as a way to make call-chaining and ufcs nicer.
>
I've been thinking and, while it may just be a side effect of my code style or my own inexperience, I honestly can't think of a situation where I'd want I'd want to use a non-@property function as an lvalue as described here.

> The limitation this imposes is that
>   void foo(int a) {...}
>   void bar(int a, int b) {...}
> cannot be called in this way:
>   foo = 2;
>   2.bar = 3;
>
> As a consequence, everyone's favorite
>   writeln = "lolwut";
> does not compile.
>
Do people really do this with any degree of frequency?  None of the examples I've seen read well to me, and readability of code is an important consideration when we need to represent semantic meaning with syntactic saccharides.

My opinion is to allow calling a function without parentheses only in UFCS (properties must be called without). Is that so hard to implement?

On 01/29/2013 08:36 PM, Minas Mina wrote:
> My opinion is to allow calling a function without parentheses only in
> UFCS (properties must be called without). Is that so hard to implement?

Implementation complexity is not too relevant. (But all proposals so far are easy to implement.)

On Tuesday, 29 January 2013 at 19:36:50 UTC, Minas Mina wrote:
> My opinion is to allow calling a function without parentheses only in UFCS (properties must be called without). Is that so hard to implement?

+1, and workaround:

@property I Do(alias fun, I)(I o)
{
    return o is null ? null : (fun(o), o);
}

foreach(p; persons)
        p.Do!(a => a.address.cityName.write());


and add -property option to compiler args.

On Tue, 29 Jan 2013 09:38:57 -0600, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/29/13 6:33 AM, eles wrote:
>> On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
>>> need to adopt the inferior C# approach.
>>
>> And there is another problem with the "superior" D approach: a typing
>> mistake in the name of a property might let you not with one property
>> that is r/w, but with two properties to which one is r/o and the other
>> is w/o.
>>
>> More, those functions might be placed several screens far one from the
>> other.
>
> I agree this is an issue. I think it's good language design to avoid
> "long-distance influence" of one declaration against another.
>
> This is a strong argument for keeping @property for write properties.
>
>
> Andrei
>

How so?
The op's argument is against having separate function declarations ala D, and for a joint getter/setter syntax. i.e.

foo { get; set; }
//   vs
int foo() { return 5; }
void fou(int x) {}

Because, as illustrated above, the two function names might accidentally be different. As the functions, like all overloads, should be 1 code-fold apart, the actual severity of the bug is the same as accidentally changing the name of an overloaded function during initial coding or during a refactor. Which is neither for nor against @property, but advocating new syntax and keywords for defining properties.