$if and $for shall _not_ introduce a scope

[nordlow]

So because

fn main() {
    $if windows {
        x := 1
    } $else {
        x := 2
    }
    println(x) // error: undefined ident: `x`
}

error as

error: undefined ident: `x`

it's clear that $if currently introduces a scope. It should not, I repeat, it should not.

Having it introduce a scope makes it impossible to optionally define make declarations of types, functions and constants, depending on the compile-time expression given to $if. If you want V to be a language that's going to be competitive in terms of expressiveness and powerful metaprogramming capabilities, please change this now. As Andrei mentions in his talk linked to below, in the case studies done in D, its static if requires absence of scope in 95 percent of its uses cases. If you want to see for yourself what scope-less static if makes possible, go into D's standard library and search for static if (or static foreach` for that matter) and look for yourself. It's branching at design space. One have to study these cases for oneself to understand what capabilities it enables.

The scope should instead be optionally enable via an extra pair of braces as

$if {{
}}

and

$for {{
}}

For motivation see Andrei's complete destruction of C++'s corresponding if constexpr at https://youtu.be/tcyb1lpEHm0?t=3000.

[dumblob]

This is an interesting observation. Thank for pointing it out!

Currently in existing V code it seems not to be a problem (code duplication is very low if any AFAIK). But the question is whether this is true also for big projects. I don't think D is the best example as it has very different type system and capabilities etc. (though it might show some trends under certain criteria). What about looking at Go? It didn't have any such compile-time capabilities as it has now (thanks to "preprocessor" etc.). Maybe it shows that there is some demand, but it's nowhere near those 95% in D? And maybe the Go's solution also doesn't allow for such fine-grained conditional compilation and rather supports "bigger chunks colocated at the expense of small code duplication"? I don't know...

I for myself would first very much like to see how much of the code is duplicated due to this "scoping" in the existing V code (at least in this v repository). Then we should weight it with the fact that the current strict scoping enforces one to write arguably slightly better structured & readable code (at the expense of some duplication). And first then we could look at Go, D and others if the answer will not be clear yet.

[nordlow]

If you think code duplication in V is low, I suggest you take a look at

https://dlang.org/phobos/std_range.html
https://dlang.org/phobos/std_algorithm.html

and think about in how many ways these algorithms can be instantiated (used). Either individually or combined. In order to answer that question you first have to read up on the concept of a lazy-evaluated D range which, in turn, is based on the concept of a C++ iterator. Do you see any overloads?

static if is much less (not at all?) relevant in Go as it doesn't (yet) have generics. The static if construct in D is all about taking generic (reusable) component programming [2] to the next level ("design by introspection") [1].

[1]
https://youtu.be/es6U7WAlKpQ?t=2147
https://www.youtube.com/watch?v=HdzwvY8Mo-w
https://www.reddit.com/r/programming/comments/6bhnss/andrei_alexandrescu_design_by_introspection_talk/

[2]
https://www.talkfrom.com/video?name=component-programming-in-the-d-programming-language-walter-bright

[dumblob]

If I understand you correctly, this is no technical question, but rather a philosophical about "to which degree V wants to enhance generics and to which degree generics should take over the language".

I think only @medvednikov can answer these questions as they closely correspond to the "simplicity" of V.

[nordlow]

Opposite to C++ or Rust for that matter, generics can be made simple. D is a proof of that.

Why doesn't V want to enhance generics when it already has templates? D has also made mistakes but they are not at all as many. V could learn from them and implement an even better enhanced generics.