comptime: support -d ident=value and var := $d('ident', 0)

[larpon]

Updated: Initial suggestion was to use -cv ident=value and $compile_value('ident', <value>), it is now an extension of -d using $d('ident', <value>) as retriever.

This PR adds support for the following:

v -d my_i64=890 -d my_string="five six" run .

const my_i64 = $d('my_i64',4)
const my_string = $d('my_string','five')

fn main() {
    println(my_i64)
    println(my_string)
}

Resulting in:

890
five six

.. and leaving out the -d flags:
v run ., outputs:

4
five

Supported types are "pure" literals, and can be used also without const:

my_f64 := $d('my_f64', 1.0)
my_i64 := $d('my_i64', 2)
my_string := $d('my_string', 'three')
my_bool := $d('my_bool', false)
my_char := $d('my_char', `f`)

I'm suggesting this, primarily, because I need to be able to tweak fixed array sizes at compile time - so that they have a default, but so I can decide to let my users tweak the sizes if they have reasons or needs to do so.

As @spytheman mentioned on Discord; It has potential to replace both (current) -d and $env.

I plan on adding support for #flag -I $d('my_flag','flag_value')/xyz and #include "$d('my_include','/usr/include')/stdio.h" when time permits. (DONE)

[StunxFS]

Great work!

[spytheman]

It is an excellent and long needed addition.
Great work!

[larpon]

Awesome, thanks @spytheman

[enghitalo]

What you guys think about use --compile-values instead of -cv flag? Or using both?

[JalonSolov]

It would be -compile-values - V only uses 1 -.

The longer name would be more explicit, for sure. -cv could be almost anything... Want V to write a Ciriculam Vitae for you? -cv. :-)

[larpon]

What you guys think about use --compile-values instead of -cv flag? Or using both?

Currently most, if not all, v flags is denoted via single dash -.
The PR supports both a short and long version:
-cv and -compile-value

(and you can even use them multiple times interchangeable: v -cv some_var=4 -compile-value xyz=4.7)

Using the plural version (with "s"; -compile-values) when multiple flags/args can be supplied is not ideal.

[spytheman]

@medvednikov what do you think about this new language feature?

[medvednikov]

I like it.

But we do have -d compvar, which does the same thing, so it would probably have to be removed for "one way"?

[medvednikov]

(well, not the same, -d is a subset of this new feature)

[larpon]

If we decide to remove -d it probably needs an extended deprecation period since it's a very "old" and very frequently used feature.

[spytheman]

We can also extend -d ident to support -d ident=value, then it can work as before for the first case (except that $compile_value(ident, false) will be true).

For the second case, it can have the new behavior, that is described here for -cv ident=value.

That way, there will be no need for a deprecation, it will continue to work, while having more functionality.

[felipensp]

We can also extend -d ident to support -d ident=value, then it can work as before for the first case (except that $compile_value(ident, false) will be true).

For the second case, it can have the new behavior, that is described here for -cv ident=value.

That way, there will be no need for a deprecation, it will continue to work, while having more functionality.

+1 on keeping -d parameter.

[spytheman]

gcc/clang's -D option also has 2 forms:
-Dname
-Dname=value
so there is an existing precedent for that.

[spytheman]

It seems to work, but I have to do more tests:

#0 15:56:47 ^ comptime/key-value /v/oo>./v -d dynamic_boehm -keepc -showcc examples/hello_world.v
> C compiler cmd: '/space/v/oo/thirdparty/tcc/tcc.exe' '@/tmp/v_1000/hello_world.tmp.c.rsp'
> C compiler response file "/tmp/v_1000/hello_world.tmp.c.rsp":
  -fwrapv -o "/space/v/oo/examples/hello_world" -D GC_THREADS=1 -I "/usr/local/include" -L "/usr/local/lib" "/tmp/v_1000/hello_world.tmp.c" -std=gnu99 -D_DEFAULT_SOURCE -bt25 -lgc -lpthread -ldl
#0 15:56:52 ^ comptime/key-value /v/oo>./v -keepc -showcc examples/hello_world.v
> C compiler cmd: '/space/v/oo/thirdparty/tcc/tcc.exe' '@/tmp/v_1000/hello_world.tmp.c.rsp'
> C compiler response file "/tmp/v_1000/hello_world.tmp.c.rsp":
  -fwrapv -o "/space/v/oo/examples/hello_world" -D GC_BUILTIN_ATOMIC=1 -D GC_THREADS=1 -I "/space/v/oo/thirdparty/libgc/include" "/tmp/v_1000/hello_world.tmp.c" -std=gnu99 -D_DEFAULT_SOURCE -bt25 "/space/v/oo/thirdparty/tcc/lib/libgc.a" -ldl -lpthread
#0 15:56:59 ^ comptime/key-value /v/oo>
#0 15:57:00 ^ comptime/key-value /v/oo>
#0 15:57:00 ^ comptime/key-value /v/oo>./v -d my_f64=2.0 -d my_int=3 -d my_string='a four' -d my_bool -d my_char=g run ./vlib/v/gen/c/testdata/use_flag_comptime_values.vv
2.0
3
a four
true
g
#0 15:57:04 ^ comptime/key-value /v/oo>

[larpon]

I'm ok with keeping -d but then the name $compile_value will be less fitting IMO. Then maybe $compile_define would be a better name - or simply $define, but that may give too many C associations?

[spytheman]

The PR is already updated to allow for -d name=value, and if everyone agrees, we can remove the code handling -cv/-compile-value in v.pref.

[spytheman]

So, $if would remain the same? Or would it be different?

The syntax of $if is not affected at all by this PR (and it would be a breaking change if it did). It is still $if name ? {.

The new $compile_value('name', default) syntax allows you to get the actual passed value, which was not possible before.

I think, that it would be too verbose to be used as $if $compile_value('say_hi', false) {, even when that is possible (it currently is not evaluated in that case, which is a bug):

$if $compile_value('say_hi', false) {
        println('say_hi is true')
} $else {
        println('say_hi is false')
}

always prints say_hi is true, even for -d say_hi=false .

[felipensp]

So, $if would remain the same? Or would it be different?

The syntax of $if is not affected at all by this PR (and it would be a breaking change if it did). It is still $if name ? {.

The new $compile_value('name', default) syntax allows you to get the actual passed value, which was not possible before.

I think, that it would be too verbose to be used as $if $compile_value('say_hi', false) {, even when that is possible (it currently is not evaluated in that case, which is a bug):

$if $compile_value('say_hi', false) {
        println('say_hi is true')
} $else {
        println('say_hi is false')
}

always prints say_hi is true, even for -d say_hi=false .

yes, $compile_value() is too verbose on if conditions. We just need to document about using -d to handling conditional code and accessing its values. How retrive value and how use it on conditions.

[larpon]

I'm ok with -d ident=value and like any of $d $define and $compile_value. $d is very nice since it matches -d.

Maybe it will be possible to do:
$if name == value ? {...}
For comptime logic?

[larpon]

Limited HashStmt support is added in e1be3eb. Currently we only support string values like with $env().

The whole # comptime setup could probably benefit from some proper refactoring at some point.

But now this works similar to $env() in #flag, #include etc.:

#flag -I $d('my_flag','flag_value')/xyz
#include "$d('my_include','/usr/include')/stdio.h"

[larpon]

Resolved conflict with master, hence the merge with master