Flag proposal

[Andrei Alexandrescu]

On 6/10/11 7:09 PM, Jonathan M Davis wrote:
> I think that there _are_ features that we need to look at adding in some form
> or other (such as conditional attributes) in order to solve current problems
> in the language (such as the inability to use many attributes - such as pure
> and @safe - with templates without excessive duplication of code). But if a
> feature does not solve a pressing problem and/or can be reasonably solved by
> improving Phobos, then we should be improving Phobos.

Good point. Walter and I agree that there are two categories of language 
change: adding new features, and removing undue limitations. At this 
point, we're planning on a lot more of the latter than the former kind.

As an example, consider:

module my_module;

void fun()
{
     import std.random;
     return uniform(0, 100);
}

int gun()
{
     import std.stdio;
     writeln(fun());
}

This module won't compile in today's D, but not for a matter of 
principles; it's just a random limitation of the language. (It does work 
if you import from within a class or struct.) You can insert most 
declarations in a scope, so the ones you can't insert are just awkward 
exceptions, unless there's a good reason to actively disable them. Any 
code should work if you just wrap another scope around it.

Walter and I call the above a "turtle feature", in allusion to the 
"turtles all the way down" meme. Walter wants to fix this, and similar 
limitations that act "unturtly". Imports inside a scope won't be visible 
outside that scope, and importing the same module from several different 
functions will come at no cost in compilation time.

This may as well lead to a different approach to defining good D 
modules, in which many imports don't come at the top unless they are of 
very general use. Functions that have special needs can always embed 
their own imports modularly without the symbols spilling out in everyone 
else's sight.

As a perk - remember Adam Ruppe's trick to build the examples on the 
site? Some have top-level code so they don't compile as they are. With 
this change, code should work if the website simply adds a unittest { 
... } around the code.


Andrei