Shared with no type in Druntime.

[Paulo Pinto]

Am 29.04.2012 05:03, schrieb Adam Wilson:
> On Sat, 28 Apr 2012 19:23:28 -0700, Jonathan M Davis
> <jmdavisProg at gmx.com> wrote:
>
>> On Saturday, April 28, 2012 18:32:00 Adam Wilson wrote:
>>> Ok, so that answers the legality of the issue, but it smacks of sloppy
>>> coding. We cannot ship the DRT as a dynamic library, as has been
>>> discussed
>>> and agreed to as a good idea, if their are variable declarations that
>>> rely
>>> on type inference from an assignment operation because those assignments
>>> will get stripped out of the DI. So what should I do then? Because
>>> shared
>>> stdin; by itself with no assignment to infer from IS illegal and
>>> there is
>>> not (that I can see) a way to separate an instantiation from an
>>> implementation and the whole point of DI files is too remove
>>> implementations.
>>
>> There's nothing sloppy about it whatsoever. If you think that that's
>> sloppy
>> coding, then you're going to think that auto is sloppy coding, and you're
>> going to be very unhappy with a lot of D code. Taking advantage of
>> such type
>> inference is considered _good_ style in D. For the most part, you
>> shouldn't
>> use the type explicitly unless you actually need to.
>>
>> If you need to put a variable in a .di file without its initializer, then
>> that's a case where you're going to need to use the type explicitly. That
>> means that either the .di generator is going to leave the initializer in
>> (which I expect is what it currently does) - in which case you'd need to
>> change it by hand - or it's going to need to take the type of the
>> initializer
>> and use that in the variable's declaration in the .di file rather than
>> using
>> shared by itself or auto or whatever it was using that involved type
>> inference.
>>
>> - Jonathan M Davis
>
> Ok, I can accept that. Explicit typing is lots of extra pointless typing
> when the compiler can just figure it out for me. But that leaves us with
> an interesting design question. Right now, DI gen is destructive, which
> means any changes I make to the DI file will get destroyed on the next
> build if I forget to remove the -H flags. Unfortunately that means that
> the DI generator is going to have to somewhat dictate coding style and
> we need to make sure that DI gen covers the broadest possible range of
> potential uses.
>
> Personally, I have no problem leaving in initializers for module level
> variables. Is that an acceptable solution to the community?
>

Maybe I have been spoiled by doing too much programming in languages 
that have module systems, but why is the initialization shown in the .di 
file?

This is an implementation issue on the module.

--
Paulo