On Sat, Apr 8, 2017 at 7:15 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:
> On Feb 22, 2017, at 12:24 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> There were some opinions on Slack that we should simply change `foo` so
> tha
> On Feb 22, 2017, at 12:24 PM, Jacob Bandes-Storch via swift-evolution
> wrote:
>
> There were some opinions on Slack that we should simply change `foo` so that
> it can *only* refer to the nullary version.
I think this is the right solution. Eventually we want to get to the point
where para
Incidentally--and I suppose I will have to repeat myself somewhere else in
the likely case that this is not seen by the people who are designing this
feature--using the sigil syntax `\foo()` nicely solves the nullary function
problem, but we get another ambiguity with the introduction of key paths
Agree.
> On Apr 6, 2017, at 8:02 AM, Xiaodi Wu via swift-evolution
> wrote:
>
> Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously
> distinguished from foo(), I think that would be the only logical result.
>
>
> On Thu, Apr 6, 2017 at 00:40 Jacob Bandes-Storch via sw
> On Apr 6, 2017, at 7:02 AM, Xiaodi Wu via swift-evolution
> wrote:
>
> Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously
> distinguished from foo(), I think that would be the only logical result.
Agree. It seem like this would fit nicely into the revision of SE-004
Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously
distinguished from foo(), I think that would be the only logical result.
On Thu, Apr 6, 2017 at 00:40 Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:
> Now that escaping with \ has been propose
Now that escaping with \ has been proposed for KeyPaths, this makes me
wonder whether it would be appropriate to use "\foo()" rather than
"foo(_)"/"foo(:)" ? It still feels a bit strange, as \foo() looks like
escaping the *result* of a call.
On Sat, Feb 25, 2017 at 1:43 PM, David Hart wrote:
>
> On 25 Feb 2017, at 00:56, Jordan Rose via swift-evolution
> wrote:
>
> I don't have a good answer for this, but I'll vote against 'foo(:)' because
> that's what a lot of people think the name of 'foo(_:)' should be. I'd rather
> be able to offer fix-its for that even when you have both 'foo
Whoops, after hitting Send I realized that I don't want to kill references to
non-member functions, which means it's still useful to have a syntax for this.
Still, there is one simple and unambiguous spelling when you need it…
{ foo() }
trollface.gif,
Jordan
> On Feb 24, 2017, at 15:56, Jorda
I don't have a good answer for this, but I'll vote against 'foo(:)' because
that's what a lot of people think the name of 'foo(_:)' should be. I'd rather
be able to offer fix-its for that even when you have both 'foo()' and 'foo(_:)'
defined. I'd rather go with 'foo(_)' despite the tiny ambiguit
I never liked the compound name syntax because parenthesis are deeply connected
to the application of function, and it breaks with the way selectors are
specified in Objective-C.
If this topic is touched once again, imho it should be done thoroughly — with a
syntax that can really eliminate all
This is clean, but given knowledge of foo(bar:) syntax, its discoverability
is low. Conversely, given knowledge of `foo()`, the discoverability of
foo(bar:) would be low compared to `foo(bar:)`.
If backticks were the *only* option, and also worked as `foo(bar:)`, the
consistency would be appealing
> On Feb 23, 2017, at 12:52 PM, Anton Zhilin via swift-evolution
> wrote:
>
> +1 to foo(:) version.
> I can easily see placeholder arguments as a sugary syntax for closures:
>
This shorthand has been explicitly rejected several times in favor of the $
argument shorthand.
> func bar(_ x: Int,
+1 to foo(:) version.
I can easily see placeholder arguments as a sugary syntax for closures:
func bar(_ x: Int, _ y: Double)
let f = bar(_, 42) // the same as:
let f = { (x: Int) in bar(x, 42) }
Now, let’s view a single-parameter version:
func foo(_ x: Int)
let f = foo(_) // the same as:
le
Does swift still use #?
foo(#)
It might be more obvious then
foo(_)
People might mistake it for foo(_:) if they are just glancing at it.
But foo(#) looks special.
On Thu, Feb 23, 2017 at 1:07 PM Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:
> FWIW, I do think the foo(_) i
FWIW, I do think the foo(_) is the best variant. For me it means "no
argument label AND no argument at all, as there is no `:` in it".
foo(_:) means "no argument label BUT one argument". etc.
As for `class()` IMO it is too cryptic. class(_) is more clear about what
it *is*(because of _ as parame
> On Feb 23, 2017, at 06:49, Xiaodi Wu via swift-evolution
> wrote:
>
> Nice. That works well.
>> On Thu, Feb 23, 2017 at 08:36 Ben Rimmington wrote:
>>
>> > On 23 Feb 2017, at 14:23, Xiaodi Wu wrote:
>> >
>> > What happens when you need the backticks for the function name itself? We
>> > ca
Nice. That works well.
On Thu, Feb 23, 2017 at 08:36 Ben Rimmington wrote:
>
> > On 23 Feb 2017, at 14:23, Xiaodi Wu wrote:
> >
> > What happens when you need the backticks for the function name itself?
> We can't nest them.
>
> func `class`() {}
>
> `class`() // Function call.
>
> `class()` // F
> On 23 Feb 2017, at 14:23, Xiaodi Wu wrote:
>
> What happens when you need the backticks for the function name itself? We
> can't nest them.
func `class`() {}
`class`() // Function call.
`class()` // Function reference.
-- Ben
___
swift-evolution
The back tick option is interesting. Back tick means "don't treat this as
an expression" which allows us to use keywords in certain areas but have
them. Act as something that isn't a keyword.
let f = `foo()`
However looking at it like this it almost looks like a string.
On Thu, Feb 23, 2017 at 9:
What happens when you need the backticks for the function name itself? We
can't nest them.
On Thu, Feb 23, 2017 at 08:16 Ben Rimmington via swift-evolution <
swift-evolution@swift.org> wrote:
>
> On 22 Feb 2017, at 07:05, Jacob Bandes-Storch wrote:
>
> *Compound name syntax* — foo(_:), foo(bar:)
> On 22 Feb 2017, at 07:05, Jacob Bandes-Storch wrote:
>
> Compound name syntax — foo(_:), foo(bar:), foo(bar:baz:) — is used to
> disambiguate references to functions. (You might've used it inside a
> #selector expression.) But there's currently no compound name for a function
> with no argum
> On Feb 22, 2017, at 2:12 PM, Richard Wei wrote:
>
> In addition, I think # and @ are very confusing since they are not one of the
> existing symbols in function name syntax.
Agreed, but it seems like every suggestion other than “foo(:)” which doesn’t
use such a character ends up potentially
In addition, I think # and @ are very confusing since they are not one of the
existing symbols in function name syntax.
-Richard
> On Feb 22, 2017, at 15:25, Richard Wei wrote:
>
> I prefer the `foo(_)` option and keeping the one-colon-per-arg rule.
>
> Intuition:
> Underscore means no label.
> On Feb 22, 2017, at 1:59 PM, David Sweeris via swift-evolution
> wrote:
>
>
>> On Feb 22, 2017, at 12:27 PM, Jacob Bandes-Storch wrote:
>>
>> Just to throw out some other options: foo(#) and foo(@).
>>
>> (And you thought we'd gotten rid of # argument labels! 😉)
>
> Between the two, I’d
> On Feb 22, 2017, at 12:27 PM, Jacob Bandes-Storch wrote:
>
> Just to throw out some other options: foo(#) and foo(@).
>
> (And you thought we'd gotten rid of # argument labels! 😉)
Between the two, I’d prefer “foo(#)”, but I don’t think either are very
intuitive.
- Dave Sweeris
___
I prefer the `foo(_)` option and keeping the one-colon-per-arg rule.
Intuition:
Underscore means no label. Colon means one argument.
foo(_:) – one arg with no label
foo(_) – no arg with no label
-Richard
> On Feb 22, 2017, at 14:27, Jacob Bandes-Storch via swift-evolution
> wrote:
>
> Just to
Just to throw out some other options: foo(#) and foo(@).
(And you thought we'd gotten rid of # argument labels! 😉)
On Wed, Feb 22, 2017 at 11:48 AM David Sweeris wrote:
>
> > On Feb 22, 2017, at 11:05 AM, Matthew Johnson
> wrote:
> >
> >
> >> On Feb 22, 2017, at 12:30 PM, David Sweeris
> wrot
There were some opinions on Slack that we should simply change `foo` so
that it can *only* refer to the nullary version.
That'd be a source-breaking change, but I'm also not sure whether it's even
solve the problem — is it true you might still have both a function and a
variable named foo accessib
> On Feb 22, 2017, at 11:05 AM, Matthew Johnson wrote:
>
>
>> On Feb 22, 2017, at 12:30 PM, David Sweeris wrote:
>>
>>
>>> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution
>>> wrote:
>>>
>>> I like this idea. I think you made the right choice of syntax given the
>>> alte
> On Feb 22, 2017, at 12:30 PM, David Sweeris wrote:
>
>
>> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution
>> wrote:
>>
>> I like this idea. I think you made the right choice of syntax given the
>> alternatives considered. To me `foo(_)` and `foo(:)` equally imply presen
> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution
> wrote:
>
> I like this idea. I think you made the right choice of syntax given the
> alternatives considered. To me `foo(_)` and `foo(:)` equally imply presence
> of an argument. The former looks like an anonymous (unname
I like this idea. I think you made the right choice of syntax given the
alternatives considered. To me `foo(_)` and `foo(:)` equally imply presence of
an argument. The former looks like an anonymous (unnamed) argument and the
latter includes the colon which only follows an argument. Between
+1
I prefer foo(:) because it matches with empty dictional literal [:].
Also, foo(_) potentially introduce a confusion.
Remember that this syntax can be appear in a pattern.
```
struct S {
let val: Int
}
func newS() -> S { return S(val: 0) }
func newS(_ val: Int) -> S { return S(val: val) }
foo(_) seems better. A colon would imply there is an argument of which
there is none.
On Wed, Feb 22, 2017 at 4:52 AM Patrick Pijnappel via swift-evolution <
swift-evolution@swift.org> wrote:
> I'm personally in favor of foo(_), as the number of colons currently
> lines up directly with the number
I'm personally in favor of foo(_), as the number of colons currently lines
up directly with the number of arguments, and it'd be good to keep it that
way.
In general though I'm very in favor of requiring the parentheses, as the
ambiguity between unparenthesized references to functions and properti
>
> On 22 Feb 2017, at 08:05, Jacob Bandes-Storch via swift-evolution
> wrote:
>
> Evolutioniers,
>
> Compound name syntax — foo(_:), foo(bar:), foo(bar:baz:) — is used to
> disambiguate references to functions. (You might've used it inside a
> #selector expression.) But there's currently n
> On Feb 21, 2017, at 11:05 PM, Jacob Bandes-Storch via swift-evolution
> wrote:
>
> Evolutioniers,
>
> Compound name syntax — foo(_:), foo(bar:), foo(bar:baz:) — is used to
> disambiguate references to functions. (You might've used it inside a
> #selector expression.) But there's currently
Evolutioniers,
*Compound name syntax* — foo(_:), foo(bar:), foo(bar:baz:) — is used to
disambiguate references to functions. (You might've used it inside a
#selector expression.) But there's currently no compound name for a
function with no arguments.
func foo() {} // no compound syntax for
39 matches
Mail list logo
