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

Reply via email to