Scope modules DIP rough messy draft.

[luckoverthere]

On Sunday, 28 October 2018 at 16:16:01 UTC, 12345swordy wrote:
> 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.

Probably for the better, importing with classes and functions is 
actually useful. Being able to define a module in those scopes 
provides nothing.

>> 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.

Ok, why not give some now?

>> 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.

Yes that's the point, which benefits classes and functions, but 
the point of a module is provide a grouping. If that grouping is 
inaccessible to anyone else then there really isn't any benefit. 
The class and function act as a grouping in this case.

>> 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!

Having nested functions and classes is useful though. Having a 
nested module within a pseudo module (the class/function) isn't 
really beneficial.

>> Not even C++ makes this mistake of allowing namespaces in the 
>> body of functions!
> No one wants c++ namespaces here, as we have modules!

Missing the point, even C++ with all its warts is smart enough 
not to implement nested namespaces in classes and functions 
(namespaces being C++'s way of grouping code vs D's modules).

>> Same thing goes for modules being defined in classes.
> We already allow nested functions and nested classes, why not 
> nested modules as well?

Because they provide little benefit, the functional purpose of a 
module is to group classes and functions. Nested classes and 
functions already have a grouping, the class/function they are 
nested in. We don't need further groupings in these cases.

>> 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!

You keep bringing up gotos, but aside from that rule you seem to 
like to follow. Gotos actually have their uses. Nested modules do 
not. Over filling a language with features also isn't a good 
thing and makes is less practical as a whole. Having too many 
features, especially ones that add little value just complicates 
the language. Making it harder to read and write for everyone. 
Not just the people that choose to use one of the features 
everyone else avoids.