On Wed, Mar 15, 2017 at 03:59:46PM +0000, Stefan Koch via Digitalmars-d wrote: [...]
> Unsupported Features include :
[...]
>  - Floating point.
[...]
>  - unions
[...]

What are the chances / what's the expected timeframe of unions being implemented?

Support for unions in CTFE is a MAJOR milestone in making std.math CTFE-able, which IMO will take D compile-time capabilities to a whole new level, because it will greatly expand the scope of what's computable at compile-time in terms of floating-point constants, lookup tables, etc..  Imagine, for example, a precomputed table of values transcendental functions with some given resolution, for fast runtime lookups.

(Of course, this also requires floating-point support in CTFE. But that should be relatively easy(?). As long as both the host and target architectures support the same set of IEEE floating-point types, which is probably the case for our currently-supported platforms.)


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

On Wednesday, 15 March 2017 at 15:59:46 UTC, Stefan Koch wrote:
> Unsupported Features include :
>
>  - Unicode/Auto-decoding support.
> NOTE: foreach(char c; string) { ... } will work since it does not auto-decode.
>
>  - Floating point.
>  - Classes
>  - unions
>  - structs containing other structs.
>  - arrays of structs
>  - arrays of arrays
>  - || and &&
>  - ref return (though I doubt it's needed)
>  - references of 64bit values
>
> And maybe other I cannot think of right now.

How long do you estimate this will take?

Can/Will some of your work on newCTFE-branch be merged onto master before _all_ these things have been fixed?

On Wednesday, 15 March 2017 at 18:52:16 UTC, H. S. Teoh wrote:
> On Wed, Mar 15, 2017 at 03:59:46PM +0000, Stefan Koch via Digitalmars-d wrote: [...]
>> Unsupported Features include :
> [...]
>>  - Floating point.
> [...]
>>  - unions
> [...]
>
> What are the chances / what's the expected timeframe of unions being implemented?
>
> Support for unions in CTFE is a MAJOR milestone in making std.math CTFE-able, which IMO will take D compile-time capabilities to a whole new level, because it will greatly expand the scope of what's computable at compile-time in terms of floating-point constants, lookup tables, etc..  Imagine, for example, a precomputed table of values transcendental functions with some given resolution, for fast runtime lookups.
>
> (Of course, this also requires floating-point support in CTFE. But that should be relatively easy(?). As long as both the host and target architectures support the same set of IEEE floating-point types, which is probably the case for our currently-supported platforms.)
>
>
> T

I am not sure.
The CTFE-ABI is different from the ABI at runtime.
So more adventurous uses of unions are likely to be surprising.
As for floating point, I have yet to find a solution that will work for more numerically inclined people.
dmds constant folder apparently does some funky things in that domain as well.
I do not anticipate to have any of the fp stuff working before dconf.

Currently Unicode correct string-handling is more important.
After that comes class support.
FP is the very last thing on my list and will like take a lot of time.

On Wednesday, 15 March 2017 at 19:00:21 UTC, Nordlöw wrote:
> On Wednesday, 15 March 2017 at 15:59:46 UTC, Stefan Koch wrote:
>> Unsupported Features include :
>>
>>  - Unicode/Auto-decoding support.
>> NOTE: foreach(char c; string) { ... } will work since it does not auto-decode.
>>
>>  - Floating point.
>>  - Classes
>>  - unions
>>  - structs containing other structs.
>>  - arrays of structs
>>  - arrays of arrays
>>  - || and &&
>>  - ref return (though I doubt it's needed)
>>  - references of 64bit values
>>
>> And maybe other I cannot think of right now.
>
> How long do you estimate this will take?
>
> Can/Will some of your work on newCTFE-branch be merged onto master before _all_ these things have been fixed?

Yes the plan is to forgo Classes Execptions and FP for newCTFE 1.0.

On Wednesday, 15 March 2017 at 16:11:44 UTC, Stefan Koch wrote:
> and string-foreach caused dmd to miscomplie itself ... *sigh*

Guess what ?
Things work so much better when you allocate space for the zero terminator :)
The segfaults are mysteriously gone :D

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

Hi Guys I am proud to say that newCTFE with string-foreach enabled, is now green!

As soon as array-length assignment (and therefore expansion) is working again;
You can start writing fast compile-time parsers.

Albeit it will be bit a bit awkward without && and ||. :o)

Today I feel like I have reached a milestone.

A good day to all of you,

Cheers Stefan.

Am 16.03.2017 um 15:48 schrieb Stefan Koch:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> Hi Guys I am proud to say that newCTFE with string-foreach enabled, is
> now green!
>
> As soon as array-length assignment (and therefore expansion) is working
> again;
> You can start writing fast compile-time parsers.
>
> Albeit it will be bit a bit awkward without && and ||. :o)
>
> Today I feel like I have reached a milestone.
>
> A good day to all of you,
>
> Cheers Stefan.

Congratulations! It's really starting to get exciting. You have no idea how much I look forward to see diet-ng run on the new engine ;-)

On Thu, Mar 16, 2017 at 04:18:35PM +0100, Sönke Ludwig via Digitalmars-d wrote:
> Am 16.03.2017 um 15:48 schrieb Stefan Koch:
[...]
> > Hi Guys I am proud to say that newCTFE with string-foreach enabled, is now green!
> > 
> > As soon as array-length assignment (and therefore expansion) is working again; You can start writing fast compile-time parsers.
> > 
> > Albeit it will be bit a bit awkward without && and ||. :o)
> > 
> > Today I feel like I have reached a milestone.
> > 
> > A good day to all of you,
> > 
> > Cheers Stefan.
> 
> Congratulations! It's really starting to get exciting. You have no idea how much I look forward to see diet-ng run on the new engine ;-)

And I'm so excited to be able to soon write complicated compile-time parsers and parser generators without drastic reduction in compilation time or drastic increase in compiler memory requirements.


T

-- 
Fact is stranger than fiction.

On Thursday, 16 March 2017 at 14:48:22 UTC, Stefan Koch wrote:
> As soon as array-length assignment (and therefore expansion) is working again;
> You can start writing fast compile-time parsers.

Though for AST one would need unions, like
struct Node
{
  int type;
  union
  {
    StringLiteral str;
    NumberLiteral num;
    ExpressionNode expr;
  }
}

On Friday, 17 March 2017 at 12:55:22 UTC, Kagamin wrote:
> On Thursday, 16 March 2017 at 14:48:22 UTC, Stefan Koch wrote:
>> As soon as array-length assignment (and therefore expansion) is working again;
>> You can start writing fast compile-time parsers.
>
> Though for AST one would need unions, like
> struct Node
> {
>   int type;
>   union
>   {
>     StringLiteral str;
>     NumberLiteral num;
>     ExpressionNode expr;
>   }
> }
You might as well replace union with struct here.