Allow local flags/enum declaration in function arguments

[dumblob]

Allow local flags declaration in function arguments - imagine something like:

fn f( x $flag1|flag2|flag3, y $flagA;$flagB;$flag ) ...

($flag1 $flag2 $flag3 are choices where exactly one must be given whereas $flagA $flagB $flagC are true flags allowing any ORed combination of them, but at least one of them)

Except for avoiding most separate enum declarations (requiring among the code clutter also each time a good descriptive but globally unique name), take a look at more interesting use cases this allows: https://github.com/daokoder/dao-modules/blob/master/web/html/example.dao (source code for the compile-time checked templating engine)

In the end general interfaces look much cleaner and are "kind of easier to use" (e.g. .trim( $space ) instead of .trim_space()).

This everything goes hand in hand with default argument values and assumes they'll be supported.

[ntrel]

$flag1 $flag2 $flag3 are choices where exactly one must be given

Can't we use a separate enum for that then?

$flagA $flagB $flagC are true flags allowing any ORed combination of them, but at least one of them)

When V has generics and varargs, maybe V can support that with a compile-time evaluated function that takes varargs of enum values:

// user code
enum Flags {
  foo = 1 << 0,
  bar = 1 << 1,
  baz = 1 << 2
}
fn f(m Mask<Flags>){
  if m.has(.baz) {...}
}
// usage:
f(mask<Flags>(.baz, .foo))

// vlib library code
struct Mask<Enum>{
  flags usize
}
fn (m Mask<E>) has(e E) {
  return m.flags & e
}
fn $mask<E>(first E, more E...) Mask<E> {...}

mask requires at least one flag. mask would check at compile-time (using introspection) that Flags defined each enum value so it didn't overlap (e.g. 1, 2, 4 instead of 1, 2, 3).

Edit: Mask is not the best name, probably it should be called Flags.

[dumblob]

Can't we use a separate enum for that then?

That's the whole point of this proposal - to not need the separate user code declaration, but just the (way shorter and more descriptive) declaration as function arguments. Your example with generics seem too overengineered - I would personally prefer a more readable solution (without has) with less compile time guarantees and with a runtime assert instead. I think you'll understand once you looked at the source code I've linked in the proposal above.

[ntrel]

way shorter

(Saving characters for a one-off declaration probably is not one of V's goals).

and more descriptive

How so? I was talking about a specific enum tailored for the function it's used with.

I would personally prefer a more readable solution (without has)

You can have that if V gets operator overloading for &.

with less compile time guarantees and with a runtime assert instead.

If V supported your proposal then it should have compile time guarantees, otherwise we would just add named arguments to V.

I think you'll understand once you looked at the source code I've linked in the proposal above.

That isn't a good example, it's not readable. Instead, look at any language that has named function arguments, that would show the main benefit too.

[ntrel]

to not need the separate user code declaration

I know, but that does make function signatures harder to read. Listing all possible arguments at the parameter site is verbose.

[dumblob]

(Saving characters for a one-off declaration probably is not one of V's goals).

It has nothing to do with saving. It's about "plain old C enums are unnecessarily verbose in most cases", so let's not use them (at all at best - we could maybe even kill them in V in favor of argument enums/flags, but that's another story I did not request in the proposal).

How so? I was talking about a specific enum tailored for the function it's used with.

Because argument-level "enums" are just in the function scope and nowhere else (even the template has approach makes everything global to achieve the "function compatibility" check). Don't forget also about lambdas which would also benefit from argument-level enums/flags.

You can have that if V gets operator overloading for &.

Sounds interesting, but I'm not convinced & operator overloading won't have any side effects (not speaking about the semantical "weirdness" exactly when it comes to arguments having references).

That isn't a good example, it's not readable.

It's not an example of code formatting, but usage. It can be formatted the same as any other nice-looking code in V. As mentioned above, the less pollution of the global (name)space, the better.

Instead, look at any language that has named function arguments, that would show the main benefit too.

No, named arguments are orthogonal to this proposal (i.e. fully unrelated). Though you're right, they can be nicely combined with flags/enums.

I know, but that does make function signatures harder to read. Listing all possible arguments at the parameter site is verbose.

solution	suitability for the most common scenario - low number of flags	suitability for high number of flags	verbosity
explicit declaration in outer scope	no	yes	moderate to high
declaration as argument in inner scope	yes	yes	lowest possible

The table summarizes all major pros and all major cons from the programmers point of view. Therefore I think there is not much point in discussing how to achieve some half-baked similar solution to the proposal. But simply answering whether it fits V and its philosophy or not. @medvednikov could stop by and since then it's solved.

[ntrel]

argument-level "enums" are just in the function scope and nowhere else (even the template has approach makes everything global to achieve the "function compatibility" check). Don't forget also about lambdas

BTW I think enums and consts should be allowed in local scope.

I'm not convinced & operator overloading won't have any side effects (not speaking about the semantical "weirdness" exactly when it comes to arguments having references).

That's an issue orthogonal to operator overloading, using operators on a reference. Operator overloading would work fine if references work with operators.

[ntrel]

For the record, I'm not saying a library approach is better in itself, just that V tries to limit the number of features to features that are flexible and general. This proposal feels quite specific (flag &-ing isn't very common). My suggestions for enhancing V to improve my library alternative are all useful to make the existing features more powerful for general use cases.