Alexander Medvednikov
abec0a455a
* parser: reject `|` and `^` operator overloads token.is_overloadable came from the tinyv parser and includes `|` and `^`, so `fn (a T) | (b T) T` parsed as an operator method and passed the checker. Nothing lowers those operators, though: transform's struct_operator_symbol only maps the documented `+ - * ** / % < ==` (and the comparisons derived from them), so `a | b` on struct operands was emitted unchanged and failed in the C compiler. V 0.5.2 never accepted these overloads (its parser reports `expecting method name` at the operator), and the docs list only `+ - * ** / % < ==`. Report the same error, at the same token. The declaration is still parsed as an operator method, so the rest of the file parses normally. A `|` inside an unclosed receiver (`fn (x int | string)`) already has its own error, so it is not reported a second time. * types: reject operator overloads on enums and interfaces The checker validated the arguments and return type of an operator method, but not its receiver kind, so `fn (a Color) + (b Color) Color` on an enum compiled. Nothing lowers such a method: transform only turns infix expressions on struct, alias and (for `==`) sum type operands into operator calls. So `Color.red + Color.red` kept the enum's integer addition and silently ignored the overload. On an interface, `==` kept the builtin interface equality and `+` left `a + b` on the interface's C struct, which failed in the C compiler. V 0.5.2 rejects these with `operator methods are only allowed for struct and type alias`, at the declaration. Report the same error for receivers that are enums or interfaces. An alias of an enum keeps overloading operators, as in 0.5.2. Unlike 0.5.2, `**` is checked too: 0.5.2 left it out of the list of checked operators. Also unlike 0.5.2, sum types are not rejected: #29578 lowers their `==` overloads, and v.types relies on one (`Type.==`). * parser: reject explicit `!=`, `>`, `<=` and `>=` overloads The docs say these operators are generated from `==` and `<` and cannot be overridden, but token.is_overloadable includes them, so `fn (a T) != (b T) bool` parsed as an operator method and transform then called it, in place of the negated `==`, for every `a != b`. V 0.5.2 rejects these declarations in its parser with `cannot overload `!=`, `>`, `<=` and `>=` as they are auto generated from `==` and `<``, at the operator. Report the same error, at the same token (0.5.2's message lacks the space before `<`; it is added here). * cgen: give operator overloads of enum aliases their own C names An alias of an enum can overload operators, but its methods are named by enum_method_c_name_in_module, which spells a method as `<Enum>_<cname(method)>`. cname of a bare operator is `_`, so every operator of the alias got the same C name (`Pitch__`): only one body was emitted, and `a - b` or `a < b` called the `+` overload. Name operator methods there the way naming.c_name names every other operator overload, in the internal namespace (`__v3_internal_symbol_op_Pitch__plus`), so they cannot collide with each other or with a method of the same word. * types: derive `>`, `<=` and `>=` from an alias's own `<` An alias that declares `<` gets `>`, `<=` and `>=` generated from it, and transform lowers them that way, but check_infix only skipped the builtin checks of the aliased type for an operator the alias declares itself. So `a > b` fell through to the checks of the aliased type: an alias of a struct without `<` reported `undefined operation`, and an alias of an enum `only `==` and `!=` are defined on `enum``. Only an alias of a primitive, whose own ordering is valid, compiled. Look up the alias's `<` for these operators, as V 0.5.2 does.
page, title, index
| page | title | index |
|---|---|---|
| index | V standard library documentation | V stdlib |
This site contains the documentation for the standard library of modules
included with the V language. Also commonly referred
to as vlib, as that is the root directory for these modules in the V
repository.
If you were looking for documentation for the language itself, the builtin types, operators, et. al., please use the V documentation link.
Some included modules depend on third party libraries, and these are kept
separate in the thirdparty directory at the root level of the source
repository.
Note that the builtin module is
implicitly imported by default in V, so you do not need to have a specific
import statement to use any of the features of that module.