Pekka Klärck

One big challenge implementing this would be deciding how overloaded methods are shown in Libdoc outputs. Just showing arguments for the final, non-overload implementation would mean that users couldn't see...

With overloads you can do this: ```python @overload def should_be_positive(number: int): ... @overload def should_be_positive(number: float): ... def should_be_positive(number): if number

I already wrote that > I know that if there are more arguments and/or return values, overloads can help to make typing more precise and your example just gives one...

I'm slightly worried can we get this done in RF 7 timeline. This would be a nice enhancement so I keep it in the scope at least for now.

The typing syntax needs to be kept in mind when deciding about #4674. Assuming it's implement, the decision between `${name: type}` and `${name}: type` isn't that important because both would...

This issue wasn't considered important enough, considering the required effort, for RF 7.

No interest towards this lately. Moving to later.

I forgot we already had this issue and submitted #4584 about `robot:flatten`. The description has lot of information about flattening in general and also has a pretty concrete design proposal...

Better to wait until a major version before making this backwards incompatible change.

I realized it's pretty easy to add backwards compatibility to our `ModelVisitor` so that old `visit_ForceTags` will continue to work. I'll commit that enhancement shortly.