Compile time opAssign/@property constraints
Jacob Shtokolov
jacob.100205 at gmail.com
Sat Jan 5 17:00:33 UTC 2019
On Friday, 4 January 2019 at 14:36:16 UTC, Mike Parker wrote:
> v is a run-time value, not available at compile time.
Sorry about that, looks like if I edit the text in the
run.dlang.io editor, the link also gets updated. I was using
"void opAssign(T)(T v)" in the initial example, but it seems that
I got the idea.
So even if I'd write opAssign or @property as a template
function, I won't be able to get their arguments at compile time
because every template takes different set of arguments: for
compile time and for run time.
And due to the fact that D is calling opAssign as
obj.opAssign(arg) and not as obj.opAssign!(arg)(arg), this is not
possible to get the runtime arguments.
On Saturday, 5 January 2019 at 01:38:43 UTC, Jonathan M Davis
wrote:
> I suggest that you read
>
> https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
>
> IIRC, it's still a work in progress, but it should give you a
> much clearer idea of how CTFE fits into things.
Many thanks for this article! Now I understand it much better.
So it seems that the only "true way" is to use the struct
invariant feature, but this will work only at run time.
It turned out that I just want some compile-time mechanism
(static analyzer?) that will validate (solve) all reachable
constraints in the program.
Then I'd like to reformulate the question: is there any tools or
compiler features that are capable of validating asserts at
compile time?
Thanks!
More information about the Digitalmars-d-learn
mailing list