Scope modules DIP rough messy draft.

[12345swordy]

On Sunday, 28 October 2018 at 12:32:57 UTC, luckoverthere wrote:
>
> The way it is implemented is promoting even poorer practices.
>
>> void function()
>> {
>>   module A
>>   {
>>     ...
>>   } }
>>
>> Which is equalivent to:
>> 
>> void function()
>> {
>>   import A;
>> }
>
> Why would you want to define a module within a function?
Not allowing it, will result the "if you can import it you can 
build it" rule being inconsistent. It no different then creating 
a separate file that is only called by one function from another 
file.
> What benefit does this provide over what you can already do?
Lots surprisingly. Don't worry, I will address the benefits that 
arise from this in the dip in the future.
> Who else is even going to be able to access this module?
The same reason for nested functions and nested classes, no one, 
that is the whole point! If you want it to be shared then don't 
put it there in the first place.
> If no one else can access it there's no point in it being a 
> module.
You can argue against nested function and nested class using that 
logic!

> Not even C++ makes this mistake of allowing namespaces in the 
> body of functions!
No one wants c++ namespaces here, as we have modules!
> Same thing goes for modules being defined in classes.
We already allow nested functions and nested classes, why not 
nested modules as well?
> Just cause you can import a module in these places, does not 
> mean you should be able to define an entire module in the same 
> place.
Nonsense, D pride itself as a practical language. That is why D 
have gotos, which if you don't like it, don't use it!