On 07/15/2012 11:11 PM, Jonathan M Davis wrote:
>
> There are two levels to enforcement. Neither exist without -property. The
> absolutely minimal level is that anything marked with @property must be used
> as a property.  Without this, you can't swap out a property function for a
> variable without breaking code.
>

If it means what I think it means then that should be done and this is
where -property fails.

> The second level - i.e. strict property enforcement - also requires that non-
> property functions be called as functions.
>

Exactly. This part is useless.

(The 'Without this, you can't...' part is notably missing.)

On Sunday, July 15, 2012 23:29:04 Timon Gehr wrote:
> > The current plan is (and has been for some time)
> > that -property will become the normal behavior,
> 
> It is obvious that -property is broken and will not become the normal behaviour.

It is obvious that -property needs to be fixed before it becomes the normal behavior. It is _not_ obvious that it will not become the normal behavior. The -property flag was created explicitly so that its implementation could be fixed _before_ making it the normal behavior and so that programmers had time to fix their code before it become enforced.

- Jonathan M Davis

On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
> > The second level - i.e. strict property enforcement - also requires that non- property functions be called as functions.
> 
> Exactly. This part is useless.

And there, we will forever disagree.

- Jonathan M Davis

On 07/15/2012 11:43 PM, Jonathan M Davis wrote:
> On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
>>> The second level - i.e. strict property enforcement - also requires that
>>> non- property functions be called as functions.
>>
>> Exactly. This part is useless.
>
> And there, we will forever disagree.
>

If it is a matter of personal preference, then it shouldn't be in the compiler.

On 07/15/2012 11:35 PM, Jonathan M Davis wrote:
> On Sunday, July 15, 2012 23:29:04 Timon Gehr wrote:
>>> The current plan is (and has been for some time)
>>> that -property will become the normal behavior,
>>
>> It is obvious that -property is broken and will not become the normal
>> behaviour.
>
> It is obvious that -property needs to be fixed before it becomes the normal
> behavior. It is _not_ obvious that it will not become the normal behavior. The
> -property flag was created explicitly so that its implementation could be fixed
> _before_ making it the normal behavior and so that programmers had time to fix
> their code before it become enforced.
>
> - Jonathan M Davis

I'd say the -property switch is there to make the fruitless
bikeshedding discussions about @property disappear. Nothing else makes
sense. Its inclusion obviously has been rushed (the error message does not even follow English grammar) and it _only_ implements the one
restriction that does not objectively matter.

On Sunday, July 15, 2012 23:47:58 Timon Gehr wrote:
> On 07/15/2012 11:43 PM, Jonathan M Davis wrote:
> > On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
> >>> The second level - i.e. strict property enforcement - also requires that non- property functions be called as functions.
> >> 
> >> Exactly. This part is useless.
> > 
> > And there, we will forever disagree.
> 
> If it is a matter of personal preference, then it shouldn't be in the compiler.

It's a matter of enforcing the correct syntax, which the compiler does all the time. It's just that you don't think that the compiler should care in this particular case, since it hasn't cared in the past.

- Jonathan M Davis

On 07/15/2012 11:56 PM, Jonathan M Davis wrote:
> On Sunday, July 15, 2012 23:47:58 Timon Gehr wrote:
>> On 07/15/2012 11:43 PM, Jonathan M Davis wrote:
>>> On Sunday, July 15, 2012 23:35:12 Timon Gehr wrote:
>>>>> The second level - i.e. strict property enforcement - also requires that
>>>>> non- property functions be called as functions.
>>>>
>>>> Exactly. This part is useless.
>>>
>>> And there, we will forever disagree.
>>
>> If it is a matter of personal preference, then it shouldn't be in the
>> compiler.
>
> It's a matter of enforcing the correct syntax,

This post seems to attempt to distract from the fact that the topic of the discussion is which syntax is correct.

> which the compiler does all the
> time. It's just that you don't think that the compiler should care in this
> particular case, since it hasn't cared in the past.
>

The compiler does not and has never 'not cared'. It has to do slightly more work. This is a designed language feature, although it's a trivial
one. eg. Eiffel and Scala have the same thing.

The prime reason why I think it is beneficial if no more restrictions
than necessary are applied is UFCS:

array(map!(x=>2*x)(range));   // should be fine

range.map!(x=>2*x).array;     // so should this

range.map!(x=>2*x)().array(); // who needs this?

On 2012-07-15 21:41, Jonathan M Davis wrote:

> And on a purely objective note, if you don't have property enforcement, you
> can't turn a property function into a variable, because even though it's
> supposed to be used as one, you can't guarantee that everyone's using it that
> way, and if they're using it as a function, changing the property into a
> variable will break their code. And part of the point of properties is to be
> able to switch between variables and property functions depending on whether
> additional protections or calculations or whatnot are required for that
> variable/property. Property enforcement is required in order to allow that.

Due to various other reasons this is still not possible.

* You cannot turn a virtual method into a variable
* For some type of variables you cannot change the variable into a method. We would need some kind of property rewrite

-- 
/Jacob Carlborg

On 2012-07-15 23:56, Jonathan M Davis wrote:

> It's a matter of enforcing the correct syntax, which the compiler does all the
> time. It's just that you don't think that the compiler should care in this
> particular case, since it hasn't cared in the past.

No, it's a matter of _what_ the correct syntax is.

Just as both of these are legal:

if (true)
    writeln(true);

if (true)
{
    writeln(true);
}

Both of these could be legal as well:

void foo ();

foo();
foo;

There are several other languages where the parentheses are optional: Ruby, Scala and CoffeeScript to mention a few.

-- 
/Jacob Carlborg

On 2012-07-16 00:33, Timon Gehr wrote:

> This post seems to attempt to distract from the fact that the topic of
> the discussion is which syntax is correct.
>
>> which the compiler does all the
>> time. It's just that you don't think that the compiler should care in
>> this
>> particular case, since it hasn't cared in the past.
>>
>
> The compiler does not and has never 'not cared'. It has to do slightly
> more work. This is a designed language feature, although it's a trivial
> one. eg. Eiffel and Scala have the same thing.
>
> The prime reason why I think it is beneficial if no more restrictions
> than necessary are applied is UFCS:
>
> array(map!(x=>2*x)(range));   // should be fine
>
> range.map!(x=>2*x).array;     // so should this
>
> range.map!(x=>2*x)().array(); // who needs this?

Exactly.

-- 
/Jacob Carlborg