Re: [swift-evolution] [Pitch #2] Introduce user-defined dynamically "callable" types

Would we really need the dynamicCall(method:arguments:) method and DynamicCallableKeywordedMethod protocol for Smalltalk-like languages? I think in these languages, we could achieve keyword-argument-sensitive method dispatch purely based on DynamicMemberLookupProtocol and

Re: [swift-evolution] [Meta] WWDC week

If there's something going on, I'll join as well. If nobody has a location for a meetup, maybe we can just meet for dinner on one day. – Alex > On 31 May 2017, at 08:09, David Hart via swift-evolution > wrote: > > I'll be there too. I don't think there is a

Re: [swift-evolution] Warn about unused Optional.some(())

Jan 2017, at 09:07, Alex Hoppen via swift-evolution > <swift-evolution@swift.org> wrote: > > This was a deliberate change between Swift 3 beta 1 and beta 2 after a friend > of mine pointed the following inconsistency out to me: > > struct Foo { > func bar() {} &g

Re: [swift-evolution] Warn about unused Optional.some(())

This was a deliberate change between Swift 3 beta 1 and beta 2 after a friend of mine pointed the following inconsistency out to me: struct Foo { func bar() {} } let foo: Foo? = Foo() foo?.bar() // Does not create a warning true ? foo?.bar() : foo?.bar() // expression of type '()?' is unused

Re: [swift-evolution] Suppress unused result warnings on try? if attempted statement does not return

I discussed the same issue in a WWDC lab with Doug yesterday and we came to the conclusion that warnings about unused return values of type Optional were a bug. The basic line of argumentation was that if you have class Foo { func bar() {} } then foo?.bar() returns Optional but does not

Re: [swift-evolution] Referencing zero-parameter functions

Since there doesn’t seem to be much support for the proposal, I’ll drop it and incorporate Alternative 1 into the #selector proposal like Doug suggested. – Alex > On 12 May 2016, at 20:52, Douglas Gregor <dgre...@apple.com> wrote: > > >> On May 6, 2016, at 12:34 AM,

Re: [swift-evolution] Referencing zero-parameter functions

Thanks for your feedback so far. Based on the discussion, I have updated the proposal to let `foo` refer to the zero-parameter function instead of `foo(_)`. The updated proposal is also available on GitHub:

Re: [swift-evolution] Referencing zero-parameter functions

, at 10:03, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> On May 5, 2016, at 8:59 AM, Alex Hoppen via swift-evolution >>> <swift-evolution@swift.org> wrote: >>>> Say you have the function `foo() -> Int`. T

Re: [swift-evolution] Referencing zero-parameter functions

Say you have the function `foo() -> Int`. Then `foo()` calls `foo` and returns its return value of type `Int` – not a reference to the function of type `Void -> Int`. As to `_`: Like I stated in the proposal the underscore is already used in functions to state that there is no parameter name.

[swift-evolution] Referencing zero-parameter functions

The idea of adding a syntax to reference zero-argument functions just like foo(arg:) is used to reference a one-parameter function has come up several times on the list. Pyry and I have put together a proposal to let foo(_) refer to a function foo without any parameters. GitHub-Link:

[swift-evolution] Disallow arbitrary expressions in selectors

During the implementation of SE-0064 (Referencing Objective-C selector of property getters and setters) I have come across an issue that could be resolved my a minor change to the language and simplify the compiler a lot. I have drafted a proposal below. Thoughts, comments, especially

Re: [swift-evolution] @noescape and nil

I think this is a bug similar to this one: https://bugs.swift.org/browse/SR-317 . Would you mind filing a bug report for it on bugs.swift.org ? – Another Alex > On 26 Apr 2016, at 09:15, Aleksandar Petrovic via swift-evolution >