digitalmars.D - Scope/block behaviour
- Eduardo Cavazos <wayo.cavazos gmail.com> Aug 19 2010
- Stewart Gordon <smjg_1998 yahoo.com> Aug 19 2010
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Aug 19 2010
- bearophile <bearophileHUGS lycos.com> Aug 19 2010
- Graham Fawcett <fawcett uwindsor.ca> Aug 19 2010
- Stanislav Blinov <stanislav.blinov gmail.com> Aug 19 2010
- "Yao G." <nospamyao gmail.com> Aug 19 2010
- "Yao G." <nospamyao gmail.com> Aug 19 2010
Hello,
I was surprised that these seem to not be allowed in D:
void main ()
{
auto a = 20 ;
{
auto a = 30 ;
}
}
void main ()
{
{ int f0 () { return 10 ; } }
{ int f0 () { return 20 ; } }
}
Perhaps I missed something in the FAQ.
Is there anywhere (manual or TDPL) I can read up on this language design
decision? What other contemporary (or classic) languages feature this
behaviour? Scheme and C both allow the above.
It seems like this would be something that might be nice for certain
shops to enforce via a compiler switch, but not on by default.
Ed
Aug 19 2010
Eduardo Cavazos wrote:Hello, I was surprised that these seem to not be allowed in D: void main () { auto a = 20 ; { auto a = 30 ; } }
Correct. http://www.digitalmars.com/d/1.0/statement.html#ScopeStatement "Even though a new scope is introduced, local symbol declarations cannot shadow (hide) other local symbol declarations in the same function."void main () { { int f0 () { return 10 ; } } { int f0 () { return 20 ; } } }
Looks like a bug.Perhaps I missed something in the FAQ. Is there anywhere (manual or TDPL) I can read up on this language design decision? What other contemporary (or classic) languages feature this behaviour? Scheme and C both allow the above. It seems like this would be something that might be nice for certain shops to enforce via a compiler switch, but not on by default.
What use case have you for this feature? Many things are legal in C(++), but nearly always mistakes and so compilers may generate warnings about them. This is another example. Generally, the route D has taken has been to make them illegal. IINM, there are always workarounds for those cases where it really is what you meant. Stewart.
Aug 19 2010
On 08/19/2010 07:06 AM, Eduardo Cavazos wrote:Hello, I was surprised that these seem to not be allowed in D: void main () { auto a = 20 ; { auto a = 30 ; } } void main () { { int f0 () { return 10 ; } } { int f0 () { return 20 ; } } } Perhaps I missed something in the FAQ. Is there anywhere (manual or TDPL) I can read up on this language design decision? What other contemporary (or classic) languages feature this behaviour? Scheme and C both allow the above. It seems like this would be something that might be nice for certain shops to enforce via a compiler switch, but not on by default. Ed
Raw text from TDPL: However, it is illegal to define a symbol that would mask a symbol in an enclosing compound statement: \begin{D-nocheck} void main() { auto widgetCount = getWidgetCount(); // Let's now open a nested block { auto widgetCount = getWidgetCount(); // /*[\codeError]*/ } } \end{D-nocheck} \indexes{masking}% As long as masking does not occur, it's legal to reuse the same symbol in different compound statements: \begin{D} void main() { { auto i = 0; ... } { auto i = "eye"; // Fine ... } double i = 3.14; // Fine too } \end{D} \begin{D-expect} \end{D-expect} \indexes{masking, hiding, name hiding, modularity}% The rationale of this setup is simple. Allowing global symbol masking is necessary for writing good modular code that's assembled out of separately compiled parts; you don't want the addition of a global variable to suddenly render various innocent bystanders uncompilable. On the other hand, enclosing-scope masking is useless as a modularity device (as there's never a case of a compound statement spanning multiple modules in~\dee) and most often indicates either an oversight aspiring to become a bug, or a cancerous function that's grown out of control. Andrei
Aug 19 2010
Andrei Alexandrescu:Allowing global symbol masking is necessary for writing good modular code that's assembled out of separately compiled parts; you don't want the addition of a global variable to suddenly render various innocent bystanders uncompilable.
When you import modules you need to ask for what you want, and not receive a lot of names you don't want. So if you add one variable and you don't import it, it shall not give the problems you say. I'd like a tidier management of global variable names. So I am not sure I agree with what is written there. Currently DMD accepts code like: int x = 1; // ... lot of code here void foo() { x++; // bug, local x undefined // ... more code here int x; x++; } void main() {} Generally in a system a big source of unwanted complexity comes from unwanted interactions between its subsystems. So I'd like D functions to be a bit more strict in where they look for names. Global variables are sometimes useful and I don't want to remove them from the language, as I think the Delight language has done. But I'd like them to be asked for in a more explicit way inside functions (in Python there is the 'global' attribute for this, but its semantics is not tidy. In D there is the leading "." to denote an outer name, but its usage is optional unless an equal local name exists). Bye, bearophile
Aug 19 2010
Hi Eduardo, I just wanted to welcome you to the list! I've come across your posts (on Scheme and Factor) on various other lists, and I've enjoyed the self-contained experiments you've posted about those languages. (You may have a compatriot in our resident member Bearophile, whose posts sometimes remind me of yours.) I hope you'll stay for a while, and share your enthusiasm and design sensibilities with the D community. Cheers, Graham On Thu, 19 Aug 2010 07:06:50 -0500, Eduardo Cavazos wrote:Hello, I was surprised that these seem to not be allowed in D: void main () { auto a = 20 ; { auto a = 30 ; } } void main () { { int f0 () { return 10 ; } } { int f0 () { return 20 ; } } } Perhaps I missed something in the FAQ. Is there anywhere (manual or TDPL) I can read up on this language design decision? What other contemporary (or classic) languages feature this behaviour? Scheme and C both allow the above. It seems like this would be something that might be nice for certain shops to enforce via a compiler switch, but not on by default. Ed
Aug 19 2010
Yao G. wrote:On Thu, 19 Aug 2010 10:22:25 -0500, Graham Fawcett <fawcett uwindsor.ca> wrote:Hi Eduardo, I just wanted to welcome you to the list! I've come across your posts (on Scheme and Factor) on various other lists, and I've enjoyed the self-contained experiments you've posted about those languages. (You may have a compatriot in our resident member Bearophile, whose posts sometimes remind me of yours.) I hope you'll stay for a while, and share your enthusiasm and design sensibilities with the D community. Cheers, Graham
Eduardo Cavazos sounds more like a spanish/latin american name, no?
Aug 19 2010
On Thu, 19 Aug 2010 10:22:25 -0500, Graham Fawcett <fawcett uwindsor.ca> wrote:Hi Eduardo, I just wanted to welcome you to the list! I've come across your posts (on Scheme and Factor) on various other lists, and I've enjoyed the self-contained experiments you've posted about those languages. (You may have a compatriot in our resident member Bearophile, whose posts sometimes remind me of yours.) I hope you'll stay for a while, and share your enthusiasm and design sensibilities with the D community. Cheers, Graham
Eduardo Cavazos sounds more like a spanish/latin american name, no? -- Yao G.
Aug 19 2010
On Thu, 19 Aug 2010 14:57:09 -0500, Stanislav Blinov <stanislav.blinov gmail.com> wrote:So? :)
So what? -- Yao G.
Aug 19 2010









Stewart Gordon <smjg_1998 yahoo.com> 