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