Jonathan M Davis:

> That's part of why I keep saying not to use in whenever it comes up. scope is
> very broken, so in is very broken. And honestly, given how often arrays are
> used in structs, I suspect that it's not at all uncommon for in to be used incorrectly.

The situation with "in"/"scope" is worse than just deprecated stuff like "delete" or "typedef". I know those things are going away, so I don't use them, and this avoids the problem.


> I believe that the only case that
> has _any_ protection at all with scope right now is delegates, which almost never should be const.

Do you mean code like this? What's bad about this? My delegate arguments
/function pointer arguments are usually const.

void foo(const int delegate(int) dg) {}
void main() {
    foo((int x) => x);
}

Bye,
bearophile

On Wednesday, September 05, 2012 01:13:00 ixid wrote:
> What does -property supposedly solve?

It's supposed to make it so that property functions are used as variables and non-property functions are used as functions, since the point of property functions is to emulate variables. It's very buggy at the moment though, so it doesn't really enforce everything that it's supposed to enforce. IIRC, it only enforces that non-property functions are called with parens and not that property functions are called without them.

> It creates a horrid mess of
> brackets that ruin the elegance of UFCS code.

You mean parens? Regardless, it means that you using functions as if there were variables, which I'm very much against. They're functions and should be called as such. But not everyone agrees.

I think that it's pretty much a guarantee that we're eventually going to end up with @property functions having to be called without parens (I don't think that very many people disagree on that). The bigger question is whether we're going to follow TDPL and also make it so that non-property functions must be called with them (as -property currently checks for). The number of parens required with UFCS (particularly with functions requiring template arguments) is one of the reasons that some people give that they think that non-property functions shouldn't be forced to be called with parens.

- Jonathan M Davis

On Wednesday, September 05, 2012 01:50:12 bearophile wrote:
> > I believe that the only case that
> > has _any_ protection at all with scope right now is delegates,
> > which almost never should be const.
> 
> Do you mean code like this? What's bad about this? My delegate
> arguments
> /function pointer arguments are usually const.
> 
> void foo(const int delegate(int) dg) {}
> void main() {
> foo((int x) => x);
> }

If you have delegates that work with const, then great, but in my experience (which frequently involves storing the delegate as a member variable), const doesn't play nicely at all with delegates.

- Jonathan M Davis

On 09/05/2012 01:50 AM, bearophile wrote:
> Jonathan M Davis:
>
>> That's part of why I keep saying not to use in whenever it comes up.
>> scope is
>> very broken, so in is very broken. And honestly, given how often
>> arrays are
>> used in structs, I suspect that it's not at all uncommon for in to be
>> used incorrectly.
>
> The situation with "in"/"scope" is worse than just deprecated stuff like
> "delete" or "typedef". I know those things are going away, so I don't
> use them, and this avoids the problem.
>
>
>> I believe that the only case that
>> has _any_ protection at all with scope right now is delegates, which
>> almost never should be const.
>
> Do you mean code like this? What's bad about this?
> My delegate arguments
> /function pointer arguments are usually const.
>
> void foo(const int delegate(int) dg) {}
> void main() {
>      foo((int x) => x);
> }
>
> Bye,
> bearophile

Similar code is the main reason for the hole in the const system.
Some people want that fixed, ergo it might break.

On 09/05/2012 02:10 AM, Jonathan M Davis wrote:
> On Wednesday, September 05, 2012 01:13:00 ixid wrote:
>> What does -property supposedly solve?
>
> It's supposed to make it so that property functions are used as variables and
> non-property functions are used as functions, since the point of property
> functions is to emulate variables. It's very buggy at the moment though, so it
> doesn't really enforce everything that it's supposed to enforce. IIRC, it only
> enforces that non-property functions are called with parens and not that
> property functions are called without them.
>
>> It creates a horrid mess of
>> brackets that ruin the elegance of UFCS code.
>
> You mean parens? Regardless, it means that you using functions as if there
> were variables, which I'm very much against. They're functions and should be
> called as such. But not everyone agrees.
>
> I think that it's pretty much a guarantee that we're eventually going to end
> up with @property functions having to be called without parens (I don't think
> that very many people disagree on that). The bigger question is whether we're
> going to follow TDPL and also make it so that non-property functions must be
> called with them (as -property currently checks for).

TDPL does not prescribe this.

> The number of parens
> required with UFCS (particularly with functions requiring template arguments)
> is one of the reasons that some people give that they think that non-property
> functions shouldn't be forced to be called with parens.
>
> - Jonathan M Davis
>

On Wednesday, 5 September 2012 at 12:05:40 UTC, Timon Gehr wrote:
>
> TDPL does not prescribe this.
>

Truth; I just checked this and indeed TDPL only mentions @property functions disavowing themselves of parentheses.  Although I've always had the distinct impression that strict property syntax was the intended future, and the current situation was just due to inheriting D1's clumsier 'property' concept.  I don't even mind all those "ugly" parens in UFCS chains, but I'm kinda crazy like that.