Am 29.04.2012 05:03, schrieb Adam Wilson:
On Sat, 28 Apr 2012 19:23:28 -0700, Jonathan M Davis
<[email protected]> 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
