On Thursday, June 07, 2018 11:31:13 jmh530 via Digitalmars-d-learn wrote:
> On Wednesday, 6 June 2018 at 22:19:58 UTC, Jonathan M Davis wrote:
> > On Wednesday, June 06, 2018 18:18:16 jmh530 via
> >
> > Digitalmars-d-learn wrote:
> >> On Monday, 4 June 2018 at 03:18:05 UTC, Jonathan M Davis wrote:
> >> > [snip]
> >> >
> >> > If you haven't yet, I'd suggest reading
> >>
> >> Would make a good blog series?
> >
> > What would make a good blog series? Something talking about CTFE?
> >
> > - Jonathan M Davis
>
> I meant that stuff describing the nuances and motivations between static/enum/etc. Maybe more tutorial or something on the wiki than blog series? It's the type of thing that isn't obvious to someone new to D, but you explain very well. Better to save it in some place easy to find than let it get buried in Learn.

I probably should do more write-ups of stuff somewhere so that I can point people to them, but for better or worse, I haven't done much of that. I've mostly just answered questions here or at stackoverflow. I did finally get my website set up though (http://jmdavisprog.com) so that I have somewhere to post articles and whatnot, but I haven't done much with it yet. Sadly, the only reason that I finally got around to setting it up was that I was pretty much forced to in order to have a place to put the documentation for dxml. Doing more useful write-ups has been on my todo list for ages but mostly hasn't ended up as a priority with everything else on my plate - which is arguably a bit dumb given how often I ultimately end up spending a bunch of time answering questions on D.Learn even when I theoretically try to not spend a lot of time replying to posts.

- Jonathan M Davis

On Thursday, 7 June 2018 at 04:58:40 UTC, Jonathan M Davis wrote:
>
> It would be trivial enough to create a wrapper template so that you can do something like
>
> immutable n = ctfe!(foo());
>
> e.g.
>
> template ctfe(alias value)
> {
>     enum ctfe = value;
> }
>

Would this be equivalent to using static immutable?

static immutable n = foo();

In this case both the compiletime and runtime values were calculated using cfte.

Also back to the OP the way I think of enum, static types is like this:

alias and enum create compiletime stuff from compiletime stuff.
static creates runtime stuff from compiletime stuff.

Is that view valid in most cases?

All this talk of CTFE and "compile-time", along with the confusion that arises from conflating everything done by the compiler into the blanket term "compile-time" makes me want to scream:

	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time

</shameless self-plug>

;-)

tl;dr: D's "compile-time" features consist of (at least) two distinct phases of code transformation: template expansion and CTFE, and having a proper understanding of exactly what they are and what the distinction between them is, will go a long way in clearing up a lot of the confusion commonly experienced by newcomers to D in regard to D's so-called "compile-time" features.


--T

On Friday, 8 June 2018 at 05:10:16 UTC, H. S. Teoh wrote:
> All this talk of CTFE and "compile-time", along with the confusion that arises from conflating everything done by the compiler into the blanket term "compile-time" makes me want to scream:
>
> 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
>
> </shameless self-plug>


Hi Teoh,  Your article is a killer!  A must read for all serious users.  Can't we navigate to this article from the DLang site?  (I mean, if I don't know the specific url, how can I reach there?)

Thanks,
Gopan

On Friday, 8 June 2018 at 05:10:16 UTC, H. S. Teoh wrote:
> All this talk of CTFE and "compile-time", along with the confusion that arises from conflating everything done by the compiler into the blanket term "compile-time" makes me want to scream:
>
> 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
>
> </shameless self-plug>
>
> ;-)
>
> tl;dr: D's "compile-time" features consist of (at least) two distinct phases of code transformation: template expansion and CTFE, and having a proper understanding of exactly what they are and what the distinction between them is, will go a long way in clearing up a lot of the confusion commonly experienced by newcomers to D in regard to D's so-called "compile-time" features.
>
>
> --T

May I suggest that you add a flow chart that gives a very high level understanding of the compiler steps. Like how Rust's introduction to MIR has:
https://blog.rust-lang.org/2016/04/19/MIR.html

On Fri, Jun 08, 2018 at 02:36:01PM +0000, Gopan via Digitalmars-d-learn wrote:
> On Friday, 8 June 2018 at 05:10:16 UTC, H. S. Teoh wrote:
> > All this talk of CTFE and "compile-time", along with the confusion that arises from conflating everything done by the compiler into the blanket term "compile-time" makes me want to scream:
> > 
> > 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
> > 
> > </shameless self-plug>
> 
> 
> Hi Teoh,  Your article is a killer!  A must read for all serious users.  Can't we navigate to this article from the DLang site?  (I mean, if I don't know the specific url, how can I reach there?)
[...]

The goal is to eventually put this article among the main articles on the wiki, but there are some loose ends that I need to clean up, and I just haven't had the time to work on it.

Perhaps I should just invite others here to edit the article, clean it up, and publish it, instead of letting it linger forever as a userpage. I just don't have enough spare time right now to do it justice.


T

-- 
What do you call optometrist jokes? Vitreous humor.

On Fri, Jun 08, 2018 at 02:57:26PM +0000, jmh530 via Digitalmars-d-learn wrote: [...]
> May I suggest that you add a flow chart that gives a very high level
> understanding of the compiler steps. Like how Rust's introduction to
> MIR has:
> https://blog.rust-lang.org/2016/04/19/MIR.html

I would, if I had the time to spare to make such a chart.  Perhaps you (or somebody here) could do it?  It *is* a wiki, after all.  Y'all don't have to wait for me to get around to it, the edit button is right there.


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.

On Friday, 8 June 2018 at 17:09:54 UTC, H. S. Teoh wrote:
>
> I would, if I had the time to spare to make such a chart.  Perhaps you (or somebody here) could do it?  It *is* a wiki, after all.  Y'all don't have to wait for me to get around to it, the edit button is right there.
>
>
> T

Fair point.

On Friday, June 08, 2018 03:51:11 David Bennett via Digitalmars-d-learn wrote:
> On Thursday, 7 June 2018 at 04:58:40 UTC, Jonathan M Davis wrote:
> > It would be trivial enough to create a wrapper template so that you can do something like
> >
> > immutable n = ctfe!(foo());
> >
> > e.g.
> >
> > template ctfe(alias value)
> > {
> >
> >     enum ctfe = value;
> >
> > }
>
> Would this be equivalent to using static immutable?
>
> static immutable n = foo();
>
> In this case both the compiletime and runtime values were calculated using cfte.

No, they're not equivalent. That template definition just forces the value to be calculated at compile time. It doesn't change anything about the variable itself. Making the variable static means that there is only one instance of the variable across all calls to the function. So, its address is not within the stack of the function. Given that the variable is immutable and thus cannot be changed means that that distinction doesn't matter a lot in this case, but there's still a difference. And if you make the variables mutable, it makes a huge difference. e.g

auto n = ctfe!(foo());

vs

static n = foo();

In both cases, the value is calculated at compile time, but in the first case, you get a unique copy for each function call that does not exist beyond that function call, whereas in the second case, it's reused for each function call, so if you mutate it, subsequent calls will see the mutated value (which would not be true if the variable weren't static).

> Also back to the OP the way I think of enum, static types is like this:
>
> alias and enum create compiletime stuff from compiletime stuff. static creates runtime stuff from compiletime stuff.
>
> Is that view valid in most cases?

Sort of but not really. enums are just names for compile-time values. As such, they have to be calculated at compile time. static variables on the other hand really have nothing to do with compile time per se. It's just that they have a single location in memory for the entire thread of the program. So, they get initialized when the thread is created and not when the function is called and as such have to have their initial value known at compile time unless a static constructor is used to initialize them. They're either intialized with the init value for their type or the value that they're given when declared. The exact same thing happens with member variables. e.g.

struct S
{
    int i = foo();
}

makes it so that S.init.i is whatever value was the result of foo. If the struct has a constructor, then that's the value of i before the constructor is called. The init value for the struct must be known at compile time, so any direct initialization is done at compile time (whereas if none is done, then the init value for the type of the member variable is used). If the member variable is const or immutable, then if it's directly initialized, then it can't be assigned in the constructor, and if it's not directly initialized, its init value is overwritten by the constructor and isn't really used. But regardless, the init value must be known at compile time, which means that any direct initialization must be calculated at compile time.

So, the fact that static variables get their intial values at compile time is just because of how they're intialized, not because of static specifically being designed with compile-time anything in mind. The result is that you then have a variable whose initial value was determined at compile time and then can be manipulated at runtime (assuming that it's mutable), but the key thing about static variables is their lifetime, not that they're initialized at compile time.

If what you're really looking for is to calculate the value of a local variable at compile-time, you're better off using an enum and then initializing the local variable with the enum than using a static variable. The only reason to use a static variable is if you specifically want a variable whose lifetime is for the duration of the thread rather than the duration of the function call. If you're using static just to get the value calculated at compile time, you're increasing how much memory your thread takes up when there really isn't a good reason to do so.

- Jonathan M Davis