Scope modules DIP rough messy draft.

luckoverthere luckoverthere at gmail.cm
Sun Oct 28 12:32:57 UTC 2018


On Saturday, 27 October 2018 at 15:25:10 UTC, 12345swordy wrote:
> On Saturday, 27 October 2018 at 15:13:11 UTC, Neia Neutuladh 
> wrote:
>> DIPs are an area where we don't trust the judgment of the 
>> person making the proposal. We need an actual argument instead.
>> A good argument here would be a single D module which is 
>> complex enough that encapsulation is necessary and where it's 
>> apparent *why* it can't just be broken up into smaller modules.
>
> I had simplify the DIP rationale as it quite apparent that 
> people are missing the forest for the trees by nitpicking the 
> design choice that hypothetical programmer may use in the 
> examples rather then focusing the underlying "one file per 
> module" restriction.
>
> -Alex

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? What 
benefit does this provide over what you can already do? Who else 
is even going to be able to access this module? If no one else 
can access it there's no point in it being a module.

Not even C++ makes this mistake of allowing namespaces in the 
body of functions. Same thing goes for modules being defined in 
classes.

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.


More information about the Digitalmars-d mailing list