core.sys.posix.unistd link error

[Ruslan Mullakhmetov]

Thanks. I suspected it but i wanted a formal reference. the 
logic, though little bit cleared by you is quite obvious. But 
don't waste time, if you can not tell  from a scratch that this 
is clause x.y.z of the Standard, sorry, Book.

On Sunday, 22 September 2013 at 19:56:36 UTC, Jonathan M Davis 
wrote:
> On Sunday, September 22, 2013 13:52:54 Ruslan Mullakhmetov 
> wrote:
>> But now i need to sort out what the difference between
>> // global scope
>> 
>> int a = 10;
>
> That directly initializes the variable at compile time, meaning 
> that whatever
> is used to initialize the variable must be callable at compile 
> time. And the
> value must be able to be set at compile time and then be 
> carried over to
> runtime. That will work with int, but it does not work with 
> most stuff that's
> on the heap (like classes or AAs) - arrays would be the major 
> exception to
> that, since they can be set at compile time (and I believe that 
> it was
> recently changed so that immutable classes could be set at 
> compile time, but
> not const or mutable ones - implementing that is rather 
> complicated, and it
> may or may not ever happen). Over time, what you can do at 
> compile time with
> CTFE (Compile Time Function Evaluation) has improved, but there 
> are still
> restrictions, and some things will never be possible (e.g. I/O 
> or calling C
> functions).
>
>> and
>> 
>> int a;
>> 
>> static this()
>> {
>>   a = 10;
>> }
>
> That does not set the variable at compile time. Rather, the 
> static constructor
> sets it at runtime. So, this has none of the restrictions that 
> directly
> initializing a module or static variable does. However, it does 
> have the
> downside that two modules that have static constructors can't 
> import each
> other (either directly or indirectly), because then the runtime 
> wouldn't know
> which order to run them in. If you do that, you'll get an 
> exception at runtime
> complaining about a circular import (which sucks, but 
> unfortunately, the
> circular import can't always be detected at compile time - 
> thanks in part to
> .di files - so runtime detection is the best that can be done). 
> So, while
> static constructors can be really nice, you do have to avoid 
> having modules
> that use them import each other, which means either being 
> careful about how
> your modules import each other or avoiding static constructors. 
> Which is
> easier depends on your code.