Re: Context sensitivity
> Bruno Medeiros: > > > I wasn't saying code conventions are good enough for all kinds of human > > errors, I was just talking about this particular one, of confusing and > > overlapping variable and type names. > > I think in this case some compiler strictness is better than code conventions. Few days ago I have opened an issue, to avoid this topic to be lost and forgotten: > http://d.puremagic.com/issues/show_bug.cgi?id=6005 > > Bye, > bearophile I think it would be ok to disallow that statically. But it is important how to do it. Disallowing shadowing a name after it has already been referenced would be the best possibility I think. It might slightly compromise compiler efficiency though, because that is additional information that needs to be stored in the symbol table. Timon
Re: Context sensitivity
Bruno Medeiros: > I wasn't saying code conventions are good enough for all kinds of human > errors, I was just talking about this particular one, of confusing and > overlapping variable and type names. I think in this case some compiler strictness is better than code conventions. Few days ago I have opened an issue, to avoid this topic to be lost and forgotten: http://d.puremagic.com/issues/show_bug.cgi?id=6005 Bye, bearophile
Re: Context sensitivity
On 06/05/2011 17:52, bearophile wrote: Bruno Medeiros, Software Engineer: This is why there are code conventions that have different rules for naming variables/fields and types, so you don't confuse them... Walter has just shown slides in D.announce that explain why sometimes code conventions aren't enough :-) Bye, bearophile I wasn't saying code conventions are good enough for all kinds of human errors, I was just talking about this particular one, of confusing and overlapping variable and type names. -- Bruno Medeiros - Software Engineer
Re: Context sensitivity
Bruno Medeiros, Software Engineer: > This is why there are code conventions that have different rules for > naming variables/fields and types, so you don't confuse them... Walter has just shown slides in D.announce that explain why sometimes code conventions aren't enough :-) Bye, bearophile
Re: Context sensitivity
bearophile wrote:
> I was away.
>
> This is D code adapted from a blog post about C language:
> http://eli.thegreenplace.net/2011/05/02/the-context-sensitivity-of-
c%E2%80%99s-grammar-revisited/
>
>
http://www.reddit.com/r/programming/comments/h23h3/the_context_sensitivity_of_cs_grammar_revisited/
>
>
> Three little D2 programs that compile with no errors. Similar code is
> allowed in C too:
>
> //
>
> alias int Foo;
> void foo() {
> Foo bar;
> float Foo;
> }
> void main() {}
>
> //
>
> alias int Foo;
> void foo() {
> Foo Foo;
> int bar = Foo + 2;
> assert (bar == 2);
> }
> void main() {}
>
> //
>
> alias char Foo;
> void foo() {
> int bar = Foo.sizeof, Foo, spam = Foo.sizeof;
> assert(bar == 1);
> assert(spam == 4);
> }
> void main() {}
>
> //
>
> Note: currently I have put nothing about this in Bugzilla.
>
> My question is: is it OK to keep allowing such kind of code in D2 too? Or
> is it better to statically forbid it?
>
> A disadvantage of statically disallowing it is the breakage of some valid
> C code. On the other hand I don't think I want to find code like that in D
> programs.
>
> Bye,
> bearophile
That's surprising, I didn't know it. I agree it should be statically
forbidden, which does not violate the principles wrt C compatibility because
it doesn't silently change semantics.
Tt also interacts with templates because they can pick up the redefined
name. Not sure if it's really a problem, it would be interesting to think of
a situation where this can occur in practice. Maybe with lots of templates,
ctfe and mixins it can became non-obvious? It sure as hell would be
confusing to run into such a bug.
Re: Context sensitivity
On 03/05/2011 11:18, bearophile wrote:
I was away.
This is D code adapted from a blog post about C language:
http://eli.thegreenplace.net/2011/05/02/the-context-sensitivity-of-c%E2%80%99s-grammar-revisited/
http://www.reddit.com/r/programming/comments/h23h3/the_context_sensitivity_of_cs_grammar_revisited/
Three little D2 programs that compile with no errors. Similar code is allowed
in C too:
//
alias int Foo;
void foo() {
Foo bar;
float Foo;
}
void main() {}
//
alias int Foo;
void foo() {
Foo Foo;
int bar = Foo + 2;
assert (bar == 2);
}
void main() {}
//
alias char Foo;
void foo() {
int bar = Foo.sizeof, Foo, spam = Foo.sizeof;
assert(bar == 1);
assert(spam == 4);
}
void main() {}
//
Note: currently I have put nothing about this in Bugzilla.
My question is: is it OK to keep allowing such kind of code in D2 too? Or is it
better to statically forbid it?
A disadvantage of statically disallowing it is the breakage of some valid C
code. On the other hand I don't think I want to find code like that in D
programs.
Bye,
bearophile
This is why there are code conventions that have different rules for
naming variables/fields and types, so you don't confuse them...
--
Bruno Medeiros - Software Engineer
Context sensitivity
I was away.
This is D code adapted from a blog post about C language:
http://eli.thegreenplace.net/2011/05/02/the-context-sensitivity-of-c%E2%80%99s-grammar-revisited/
http://www.reddit.com/r/programming/comments/h23h3/the_context_sensitivity_of_cs_grammar_revisited/
Three little D2 programs that compile with no errors. Similar code is allowed
in C too:
//
alias int Foo;
void foo() {
Foo bar;
float Foo;
}
void main() {}
//
alias int Foo;
void foo() {
Foo Foo;
int bar = Foo + 2;
assert (bar == 2);
}
void main() {}
//
alias char Foo;
void foo() {
int bar = Foo.sizeof, Foo, spam = Foo.sizeof;
assert(bar == 1);
assert(spam == 4);
}
void main() {}
//
Note: currently I have put nothing about this in Bugzilla.
My question is: is it OK to keep allowing such kind of code in D2 too? Or is it
better to statically forbid it?
A disadvantage of statically disallowing it is the breakage of some valid C
code. On the other hand I don't think I want to find code like that in D
programs.
Bye,
bearophile
