Fix discrepancies in std modules

[sa-tasche]

Examples

• std::core::types
  • is_same($TypeA, $TypeB) vs @has_same(#a, #b, ...)
  • to: @is_same($TypeA, $TypeB)
  • is_equatable_type($Type) vs @equatable_value(#value) (where is_equatable_value is @deprecated)
    • to: @equatable_type($Type) @const
• elsewhere
  • fault ConversionResult vs fault BacktraceFault vs fault AllocationFailure vs fault NumberConversion
    • to: fault *Failure? or something else?
    • fault NumberConversion is descriptive which I prefer. So, not any fault should be renamed; if descriptive.

For functions prefixed with @ (like @equatable_type) there should be a rule when @ must be set.
I think if all parameters are prefixed with $ or #, and only then, they should be prefixed with @.
So Something($TypeA, $TypeB) but not with SomethingElse(any p, $Type) (I think that's not allowed anyway).

There should also be a rule for what must be after an fault-type. (Failure or nothing).
Result is not meaningful enough for me, because a result can be an error, but does not have to be.

[lerno]

@ is required for macros if the argument is lazily evaluated (like #a), or captures by reference (&a) or must be a compile time constant ($i), and if the macro takes a trailing body. This is to highlight that it has non-function like behaviour.

As for is_same and @has_same those names are deliberately chosen to match the module prefix:
types::is_same(...) and values::@has_same(...). I am somewhat unhappy with the plural module name: type::is_same(...) and probably value::@is_same_type(...) would be an improvement.

Regarding the faults, some care has to be take so that they are unique, as they are intended to be used stand-alone without prefix. Cutting them down in size is desirable though. "Result" is usually correct as it is describing an alternative result to the "normal" result and works to differentiate the name. But I definitely would appreciate suggestions.

[sa-tasche]

Ok, but why are there functions prefixed with "@" and "$"-aguments and functions with such arguments but without "@"?

[lerno]

$Type arguments are fine without @ otherwise you should not see those.

[sa-tasche]

OK. Now we're back to my first post: inconsistency.
If the ‘@’ is optional, why add it at all?