Open Radar

 
Summary:
There are a couple of limitations that I want to address:

1. You can’t provide default implementations in protocols with extensions.
2. Functions like map() are provided both as generic implementations in the stdlib and as methods on e.g. Array, but not on e.g. Range, leading to duplication, confusion, and frustration. For example: why can I call .map() on arrays but not on ranges, but I can use both of them as the right hand side of for/in?

I suggest that functions taking at least one parameter be callable as methods on that parameter. For example, instead of reverse(someCollection), you could do someCollection.reverse(); and instead of countElements(string), you could do string.countElements().


Steps to Reproduce:
N/A

Expected Results:
N/A

Actual Results:
N/A

Regression:
N/A

Notes:
This allows you to provide default functionality for protocols and specialized types, while also allowing the language to unify the notion of methods and functions. This also further unifies methods and operators.

Presumably method resolution would start with methods found in the type or extensions, and then fall back to functions.

It’s worth noting that this would also allow method().call().chaining() syntax for functions which are specialized in type, which is very important in making pipelines, maps/filters, and similar chains readable. For example, a lazy flatten function for a collection of collections is expressible as a function with specialized type, not as a method in an extension on a collection; however, nested flattening with functions’ globally-resolved syntax is difficult to reason on at a glance. Contrast:

    thingsOfThingsOfThings.flatten().flatten()

with:

    flatten(flatten(thingsOfThingsOfThings))

Editing the latter is more involved, too—making sure you get those parentheses balanced out is a chore.

As a final note, it’s not immediately clear whether this should count towards the requirements specified in a protocol, but I’d vote yes.