>You've been busy! Looks like you've hit your 2 article limit.
>
>Log-in or register for a free account to get unlimited articles and full access to Dr. Dobb's.

Sorry doctor, but I don't care about that other article that much. My god, Dr. Dobb's is such a shit-hole. Walter's articles are their only redeeming feature.

On 2012-05-09 19:05, Adam Wilson wrote:

> This pull fixes this problem and a bunch of others:
> https://github.com/D-Programming-Language/dmd/pull/928. However, it
> currently fails to build on Linux and fails the unittests on Windows
> thanks to a problem with the dur template function in std.datetime. The
> solution used by this pull is to include the function body of the
> auto-function as that was needed to allow Phobos to build correctly
> using the DRT DI files. This is the only workable solution as DMD does
> not know the type of an auto-function when DI files are generated. No
> semantic analysis has been performed and since semantic analysis could
> change the layout of a module you wouldn't want it to be
> performed.
>

The correct way to solve this in the long run is to have the compiler replace "auto" with the inferred type. If the whole semantic analysis phase cannot be run the we need to have some kind of limited semantic analysis phase or some other phase to infer the types.

-- 
/Jacob Carlborg

On 2012-05-09 20:54, Adam Wilson wrote:

> Nuts. It's CTFE. Because the implementation source is being stripped
> out, that was *THE* main request of DI files and they are pointless
> without that.
>
> Essentially DI files and CTFE are mutually exclusive.

No, it's the same issue with templates and inline. C/C++ headers have the same issue. If you want to have a CTFE function you need to include it in the DI file.

-- 
/Jacob Carlborg

On 2012-05-09 16:30, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/telhj/voldemort_types_in_d/
>
> Andrei

D also have some problems with voldemort types. As can be seen in a discussion in the main newsgroup, it's not possible to declare a function pointer which returns by reference.

ref int function () bar;

test.d(8): Error: variable test.bar only parameters or foreach declarations can be ref

Then if we try place "ref" after "function" we get another error.

int function ref () bar;

test.d(8): found 'ref' when expecting '('
test.d(8): basic type expected, not (
test.d(8): function declaration without return type. (Note that constructors are always named 'this')
test.d(8): found 'bar' when expecting ')'
test.d(8): no identifier for declarator int function(int())

-- 
/Jacob Carlborg

On Wednesday, May 09, 2012 22:11:20 Jacob Carlborg wrote:
> On 2012-05-09 20:54, Adam Wilson wrote:
> > Nuts. It's CTFE. Because the implementation source is being stripped out, that was *THE* main request of DI files and they are pointless without that.
> > 
> > Essentially DI files and CTFE are mutually exclusive.
> 
> No, it's the same issue with templates and inline. C/C++ headers have the same issue. If you want to have a CTFE function you need to include it in the DI file.

Yeah. You _can_ strip them out (except for templates), but doing so restricts what you can do (in this case, killing inlining and CTFE). Personally, I think that it makes .di files essentially useless except in specific cases where you can't use CTFE anyway and inlining isn't an issue (e.g. much of std.file wouldn't need its implementation available, but that would be fatal to a module like std.string).

- Jonathan M Davis

On 05/09/2012 10:09 PM, Jacob Carlborg wrote:
> On 2012-05-09 19:05, Adam Wilson wrote:
>
>> This pull fixes this problem and a bunch of others:
>> https://github.com/D-Programming-Language/dmd/pull/928. However, it
>> currently fails to build on Linux and fails the unittests on Windows
>> thanks to a problem with the dur template function in std.datetime. The
>> solution used by this pull is to include the function body of the
>> auto-function as that was needed to allow Phobos to build correctly
>> using the DRT DI files. This is the only workable solution as DMD does
>> not know the type of an auto-function when DI files are generated. No
>> semantic analysis has been performed and since semantic analysis could
>> change the layout of a module you wouldn't want it to be
>> performed.
>>
>
> The correct way to solve this in the long run is to have the compiler
> replace "auto" with the inferred type. If the whole semantic analysis
> phase cannot be run the we need to have some kind of limited semantic
> analysis phase or some other phase to infer the types.
>

The type cannot be inferred without full semantic analysis in general. Furthermore, it could be different based on compilation options (or maybe based on in what order the modules were passed to DMD on the command line.)

On 5/9/2012 1:35 PM, Jonathan M Davis wrote:
> Yeah. You _can_ strip them out (except for templates), but doing so restricts
> what you can do (in this case, killing inlining and CTFE). Personally, I think
> that it makes .di files essentially useless except in specific cases where you
> can't use CTFE anyway and inlining isn't an issue (e.g. much of std.file
> wouldn't need its implementation available, but that would be fatal to a
> module like std.string).

Consider the garbage collector. There's no way you'd want to CTFE that. It makes perfect sense to only provide an interface to it (.di) rather than full source.

And for many other things.

On 5/9/2012 10:11 AM, Sean Kelly wrote:
> If the struct were made static and given a ctor that seed were passed to, I imagine it would work, yes?

It should work.

But you'll run into another issue - transmitting that typeof *up* out of its scope.

On Wednesday, May 09, 2012 14:06:10 Walter Bright wrote:
> On 5/9/2012 1:35 PM, Jonathan M Davis wrote:
> > Yeah. You _can_ strip them out (except for templates), but doing so restricts what you can do (in this case, killing inlining and CTFE). Personally, I think that it makes .di files essentially useless except in specific cases where you can't use CTFE anyway and inlining isn't an issue (e.g. much of std.file wouldn't need its implementation available, but that would be fatal to a module like std.string).
> 
> Consider the garbage collector. There's no way you'd want to CTFE that. It makes perfect sense to only provide an interface to it (.di) rather than full source.
> 
> And for many other things.

Yes. There _are_ cases where not providing the whole source makes sense, but I really think that that's the exception rather than the rule given the need for the full source for CTFE and inlining. I also suspect that in a lot of cases, automatically generating .di files makes no sense, because you need control over what is and isn't available. Using automatic generation as the base and then editing it makes a lot of sense, but blindly doing it on an entire project like we do with druntime is probably a mistake. And Adam's Wilson's attempt to make the .di generation strip out as much as possible makes that even worse.

- Jonathan M Davis

On 2012-05-09 23:03, Timon Gehr wrote:

> The type cannot be inferred without full semantic analysis in general.
> Furthermore, it could be different based on compilation options (or
> maybe based on in what order the modules were passed to DMD on the
> command line.)

That has to be solved, somehow.

-- 
/Jacob Carlborg