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