Fridtjof Siebert
Fridtjof Siebert
Within our base libraries, we should probably stick to `debug`, `safety` and `analysis`, maybe we might add a higher debug level in case the check would have a dramatic performance...
I think the type is usually clear from the context, no need to include the type parameters unless this results in ambiguity.
Nope. Semantically, they both return the length. The difference is that `length` guarantees to be in _O(1)_ while `count` might be in _O(result)_. So, whenever you see `count`, alarm bells...
> [@fridis](https://github.com/fridis) Okay, but one could argue that if `finite = finite.yes` then `count` is also guaranteed to be _O(1)_ For a `Sequence`, this is not the case, we can...
If we did this, I would suggest that this is a form of destructuring, i.e., `a, b` should be a tuple `(a, b)` and `match` should support destructuring and pattern...
This might be easier than it appears to be: For any operation on `numeric` whose result type is `numeric.this`, we could propagate the expected type provided that the target is...
This is related to #2471.
what are you trying to test with such tests?
this is similar to #3458 where `:` can cause confusion.
With #1209, `Monoid1` is now automatically expanded to `demo1_unit_types.this.Monoid1`, so the example give an error now ``` > ./build/bin/fz ex_1201.fz /home/fridi/fuzion/work/ex_1201.fz:22:38: error 1: Incompatible types when passing argument in a...