On Thursday, 19 August 2021 at 15:42:27 UTC, evilrat wrote:

Use it for something right away and it will get locked. From the spec:

On Thursday, 19 August 2021 at 16:56:22 UTC, jmh530 wrote:

smart evil

On Thursday, 19 August 2021 at 19:54:09 UTC, Basile B. wrote:

to be honest:

The situation is like we have now a feature nobody gives a shit about.
While type functions should have been something big and interesting.

I suspect that this feature nobody cares about was motivated by
the newCTFE failure, which has caused a serious trusting issue in Stefan work.

I cannot be more honnest. This is really what I think.

On Thursday, 19 August 2021 at 20:16:19 UTC, Basile B. wrote:

and obviously I dont expect Walter Bright to answer: "yes you're right".
What kind of human being pubicly recognize their errors ?

On Thursday, 19 August 2021 at 20:16:19 UTC, Basile B. wrote:

Tbh, the target of making a vm for compile time code was too high of a jump, hence epic crash. Before even attempting to do a vm for the compile time code, the compiler itself should've been in right state to be able to reuse existing components.

The target for new ctfe should've been something less grandiose, than full blown vm, and backend for it.

I really, anticipated that feature, since aedi (dependency injection lib) I've written relies on heavy template recursion and hence high compile time, and got really disappointed when nothing really came out of all advertising I've been seeing that time, really it should've been kept quiet, or as concise as possible instead of being loud all over forums.

R.I.P. (as far as I know) new ctfe on fancy vm.

Regards,
Alexandru.

On Thursday, 19 August 2021 at 20:40:30 UTC, Alexandru Ermicioi wrote:

What other alternative is there? The existing interpreter is fundamentally slow, but there aren't many alternatives to roughly what Stefan was trying to do.

The issue is that parts of dmd are written with absolutely no concept of a big picture whatsoever and dependency resolution is done like a chimp let loose in an operating theatre. Writing something like newCTFE should not be that hard (You can write a bytecode interpreter in literally half a day, and translate an AST to that byte in another day - a week if you want test coverage), but as far as I can tell you end up with horrific problems because the "interpreter" is not an interpreter as per se but rather a glorified constant-folding step - i.e. things are still being resolved as the folding (all this wrapped in an awful interface, too! e.g. null can mean all kinds of things inside dmd - like not resolved, couldn't resolve, not present, haven't tried yet etc. in the same place) so what should be a simple task ends up going from balancing a stick to balancing an n-pendulum on your nose.

https://youtu.be/cyN-CRNrb3E

newCTFE also isn't dead, as far as I know it's blocked on something like exceptions - although I wouldn't call it exactly alive either. Some of that is Stefan's fault, some it is just fundamental to the problem. As for Stefan personally, he does get distracted and he should be much more complete in documenting what he is up to, but equally who else is doing anything else even remotely interesting? Since 2017 we've gained, what, static foreach? Innovation is hard, the state of our existing stuff isn't helping.

Simple guideline for future big (>10 commits) projects for D: They must be developed either in an official fork or in a branch in an official project, otherwise they'll wither and die without being seen by enough eyes.

On Thursday, 19 August 2021 at 21:01:14 UTC, max haughton wrote:

dmd -i came since then! And a few little things like more uda locations.

But dmd -i is by far the biggest thing in years. Pity its author got pushed out of further contributions by the broken process.

On Thursday, 19 August 2021 at 21:21:33 UTC, Adam Ruppe wrote:

We also got copy constructors, or is that not a big deal?

What happened to the contributor? Was it really bad procedure on our part?

On Thursday, 19 August 2021 at 20:40:30 UTC, Alexandru Ermicioi wrote:

What you say is moslty true, however there's a detail that you forget : it was also supposed to reduce memory use.

Anyway what I said yesterday, i reprhase because i was a bit "tired" let's say, is that I think that this failure had a negative impact on how type functions were perceived. newCTFE was sold to the community : many forum posts, several videos, a DConf talk, many hours spent to develop or to rebase...
So this was legit to be a bit doubtful when the same guy comes and say "new ctfe was BS, type functs is what we need"... but the answer to this doubt, so AliasAssign, was not great.

On Thursday, 19 August 2021 at 21:01:14 UTC, max haughton wrote:

I've always wondered, what was the problem to use ast as bytecode instead of actual bytecode. I.e. have an interpreter that puts the results on a stack, and all allocations done on a special region of heap, and then drop them as soon as the result is available, or is this how const folder/ctfe works now?

You're saying the exact thing I said, compiler isn't ready for a vm that works on bytecode. Also apparently a bytecode and vm for a simple calculator could be written in half day, not for a more complex language, per my observations of reports done during new ctfe development.

So it is a zombie. I hope at least some parts of this zombie could've been merged into dmd, not necessarily something that improves ctfe.

Well that means that existing stuff needs to be improved so innovation can go, otherwise it would be the case that for a single change entire compiler would need to be modified (if going to edge).

Or just by being public, and referenced on forums, so anyone can fork and contribute to it.

Regards,
Alexandru.