`as_string` should result in an ambiguous call if called on valid types
Practically all features inherit from Any, including Type (the parent of all cotypes), therefore the features declared in Any appear in any feature as normal features and as type features.
Since .type can be omitted for type features, an ambiguity error should be raised if a normal and a type feature share the same name (except if the type feature is called explicitly with the prefix .type.
If this is strictly enforced (which is currently not the case) all features from Any will result in ambiguity errors. Then my_feat.as_string will become (id my_feat).as_string. Wouldn't that be a bit annoying?
I guess
Type.as_stringresults in an ambiguous call, right? If so, does the error suggest alternatives that are unambiguous and do they work? If not, please create a bug issue. [...] Features inherited fromAnyby a featurefshould appear twice, as inner features offand as type features off(i.e., inner features off's cotype).
Originally posted by @fridis in https://github.com/tokiwa-software/fuzion/issues/3716#issuecomment-2333782876
Type.as_string can not be called due to the visibility module:public of Type.
Well, not really. Only if you call x.as_string where x is a valid type. Usually, you would call x.as_string on a value, either by reading a field x or by calculating someing like (a+b).sign.as_string. These should all be unambiguous. Only if you do things like container.as_string you will get a warning and you will have to write container.type.as_string or (id container).as_string die resolve the ambiguity. That is IMHO justified.
If I understand correctly what you write, Type.as_string apparently causes an error right now. That should not be the case, since due to the visibility, Type cannot be a constructor call, so Type.as_string can only be Type.type.as_string.
Oh right, I forgot about this.
This call is ambiguous and should cause an error. Same for all other features in Any.
> fz -e "say Any.as_string"
instance[Any]
Same for other features without parameters, e.g. Exit_Handler.as_string or nil.as_string
Call.java:2359
/* omitting dot-type does not work when calling
the inherited methods of `Type`. Otherwise we
would always have an ambiguity when calling `as_string` */