`basename` and `size` should have explicit `String` overloads

[peterhuene]

The basename function

Currently the basename function has two overloads defined in the spec:

String basename(File, [String])
String basename(Directory, [String])

But it then goes on to say:

Parameters

File|Directory: Path of the file or directory to read. If the argument is a String, it is assumed to be a local file path relative to the current working directory of the task.

The issue here is that String is coercible to both File and Directory and so calling it with a String is technically ambiguous; the ambiguity was introduced with the addition of the Directory type in 1.2.

An ambiguity like that makes it more difficult to do the type calculus on an expression in a generic way, especially for function calls that may have type parameters. While in this specific case, we know that basename("foo") has type String for its expression because all of the overloads that are ambiguous return String, that may not be the case for some other function where the overloads differ on return type. In both cases I would want my type calculator to report on the ambiguity in binding the function arguments.

Additionally, depending on how an engine is implemented, it might not be possible to know what the "original" type was following a coercion, so it might prove difficult to fulfill the requirement of "If the argument is a String, it is assumed to be a local file path relative to the current working directory of the task." unless the engine knows the call was dispatched to the String overload of the function.

I propose we add the following overload to basename and amend its parameter description to String|File|Directory:

String basename(String, [String])

The size function

The size

Float size(File|File?, [String])
Float size(Directory|Directory?, [String])
Float size(X|X?, [String])

For the same reason as above, a call with String for the first argument would be ambiguous between all the first two overloads only; it would not bind to the third overload due to the type constraint on X (any compound type that contains File or File? nested at any depth), as String does not satisfy that constraint.

Thus, I propose adding this additional overload:

Float size(String|String?, [String])

We should also include the same note as that for baseline regarding the String overload, i.e. "If the argument is a String, it is assumed to be a local file path relative to the current working directory of the task."