On Sat, 28 Apr 2012 18:23:30 -0700, Ali Çehreli <[email protected]> wrote:
On 04/28/2012 06:08 PM, Adam Wilson wrote:
Ok. So i've been trying to build Phobos with my new DI generation code
(available here: https://github.com/LightBender/dmd.git) and i've run
into an interesting usage of shared in the D Runtime. Namely, it has no
type. I've been told that this is not correct and it should have a type.
Is that correct?
Currently the source file (stdio.d in the DRT) has this in it and it
compiles successfully:
private extern shared FILE[_NFILE] _iob;
shared stdin = &_iob[0];
shared stdout = &_iob[1];
shared stderr = &_iob[2];
shared stdaux = &_iob[3];
shared stdprn = &_iob[4];
With the new DI generation code stdio.di contains this:
private extern shared FILE[_NFILE] _iob;
shared stdin; (Errors here and all subsequent lines in this snippet)
shared stdout;
shared stderr;
shared stdaux;
shared stdprn;
Is D doing some kind of type inference based on the type of the _iob
variable in the first example that causes DMD to throw an error with the
"= &_iob[0];" part removed?
Yes. D does type inference all the time. Most of the time 'auto' is used
because most variables have automatic storage class. The following are
all legal:
void main()
{
auto a = 42; // int
const c = "hello"; // string
immutable i = 1.5; // double
struct S
{}
shared s = new shared(S); // S*
enum e = [ 0, 1 ]; // int[]
}
All of the standard streams are of type File:
assert(typeid(stdin) == typeid(std.stdio.File));
Ali
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.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
