View mode: basic / threaded / horizontal-split · Log in · Help
September 04, 2012
Re: scope for array parameters
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
September 05, 2012
Re: scope for array parameters
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
September 05, 2012
Re: scope for array parameters
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
September 05, 2012
Re: scope for array parameters
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.
September 05, 2012
Re: scope for array parameters
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
>
September 05, 2012
Re: scope for array parameters
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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home