<div dir="ltr">Weird idea based on #1: since some folks were discussing having "$$" as a special identifier meaning "all arguments" in a closure, perhaps the special parameter label could be $$ as well?<div><br></div><div> concatenate(mytuple.0, mytuple.1)</div><div> concatenate($$: mytuple)</div><div class="gmail_extra">
<br><div class="gmail_quote">On Wed, Feb 10, 2016 at 1:21 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, since SE-0029 has been accepted, let's think about explicit replacements. So far, I've been able to think of three general approaches. For the examples below, I'll assume there's a `func concatenate(number: Int, to string: String) -> String`, which does the obvious thing. Where supported, I will fully qualify names with SE-0021 syntax, but in some cases this might not be necessary.<br>
<br>
1. Special parameter label.<br>
<br>
`concatenate` is implicitly overloaded with a `func concatenate(parameters: (Int, String)) -> String`.<br>
<br>
concatenate(parameters: tuple)<br>
tuples.map(concatenate(parameters:))<br>
<br>
Advantages:<br>
- Does not require any new call-side syntax.<br>
- Googleable thanks to use of identifiers.<br>
<br>
Disadvantages:<br>
- Could conflict with functions that use `parameters` as an argument label.<br>
- Not clear how it would distinguish between `concatenate(_:to:)` and e.g. `concatenate(_:with:)`.<br>
- Might reintroduce type checking complexity, since it's adding overloads.<br>
- A bit wordy.<br>
- As far as I know, not precedented in other languages.<br>
<br>
2. Method on functions.<br>
<br>
`concatenate` has a method on it called, say, `apply(to:)` which takes a tuple of parameters.<br>
<br>
concatenate(_:to:).apply(to: tuple)<br>
tuples.map(concatenate(_:to:).apply(to:))<br>
<br>
Advantages:<br>
- You can be sure of the variant you're selecting.<br>
- Googleable thanks to use of identifiers.<br>
- Similar to usage in Javascript.<br>
<br>
Disadvantages:<br>
- Rather wordy, with lots of chaining and extra parentheses.<br>
- Methods on unapplied functions might be a little confusing.<br>
<br>
3. Splat operator.<br>
<br>
An operator like `*` is used to indicate splatting. A tuple can be put to the right of the operator to splat it in immediately, or it can be omitted to select a splattable version of the function.<br>
<br>
concatenate(_:to: *tuple)<br>
tuples.map(concatenate(_:to: *))<br>
<br>
Advantages:<br>
- You can be sure of the variant you're selecting.<br>
- Similar to usage in Ruby and Perl 6.<br>
- Fairly short in all forms.<br>
<br>
Disadvantages:<br>
- Not Googleable.<br>
- New magic syntax.<br>
- Two slightly different forms depending on whether you're calling or not.<br>
<br>
Any thoughts on these, or alternative approaches (as opposed to small syntax tweaks)?<br>
<br>
<br>
<br>
P.S. As for pointers potentially using prefix `*` for memory dereferencing, I would instead make them use postfix `!`. `!` could become an `unwrapped` pseudo-property that any type can use, democratizing another piece of `Optional` magic and working around the vexing problem of what you name the `Pointer` property for "that thing you're actually pointing to".<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</font></span></blockquote></div><br></div></div>