Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution > wrote: > > One major example is the NS/UITableViewDataSource or Delegate - there are > many many methods that you don't need to implement, hence are optional. > > But I think that this was partially

Re: [swift-evolution] [Proposal] Type Narrowing

> Le 14 nov. 2016 à 10:10, Haravikk a écrit : > > >> On 13 Nov 2016, at 16:16, Jean-Daniel via swift-evolution >> > wrote: >> >>> >>> Le 13 nov. 2016 à 03:37, Dennis Lysenko via swift-evolution >>>

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

One major example is the NS/UITableViewDataSource or Delegate - there are many many methods that you don't need to implement, hence are optional. But I think that this was partially solved by default implementation of protocol methods, which pretty much does what you want... > On Nov 15,

Re: [swift-evolution] guard let x = x

On Mon, Nov 14, 2016 at 10:41 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > I believe that covers all the major points of this discussion. If so, I'm > going to table this until phase 2. I seem to recall another possibility that was brought up in this thread, which

Re: [swift-evolution] guard let x = x

> On Nov 14, 2016, at 12:24 AM, Jonathan Hull via swift-evolution > wrote: > > >> On Nov 11, 2016, at 2:48 PM, Chris Lattner > > wrote: >> >>> To summarize: >>> >>> 1. Swift needs to introduce a `Result` type. >>

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On Nov 14, 2016, at 16:10 , Benjamin Spratling via swift-evolution > wrote: > > Given optionals and closures, is it necessary to support optional protocols? > > protocol MyProtocol { > var titleForRow:((_ indexPath:IndexPath)->(String))? { get } > } Well,

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

The disadvantage is that it's easy in Swift to push millions of things in protocols, and end up with: class MyClass: SwiftProtocollable, MoreFunctionalityable, MoreHereable, StillMoreable, ThisTooable, StillMoreable { ... } Given enough thought, maybe this can be avoided, but the

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

Given optionals and closures, is it necessary to support optional protocols? protocol MyProtocol { var titleForRow:((_ indexPath:IndexPath)->(String))? { get } } One disadvantage is that you need Obj-C, which means it doesn’t run on linux, or several other platforms. Another

[swift-evolution] Will Swift ever support optional methods without @objc?

Will Swift ever support optional methods without @objc? What are the disadvantages of marking a protocol @objc? Thanks! -- Rick Mann rm...@latencyzero.com ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] Symmetrical operators

> On Nov 14, 2016, at 5:48 AM, Haravikk via swift-evolution > wrote: > > I'm a +1 on the feature, though for simply handling symmetry it's not a super > critical issue. > > > I wonder though, when you start looking at symmetry is it worth looking at > other

Re: [swift-evolution] Selector for current method

This doesn’t seem unreasonable, but I’m not sure if that makes it reasonable. :-) What’s your use case? The stripped-down code seems like it could use any unique key, including #function. Jordan > On Nov 13, 2016, at 15:50, Rudolf Adamkovič via swift-evolution >

Re: [swift-evolution] Symmetrical operators

Perhaps a more general solution would be a way to mark functions as “rearrangeable”, meaning the arguments can appear in any order. I also like Haravikk’s idea for “outfix” operators—there are certainly a large number of bracket-type Unicode characters that could be useful in such a role. Nevin

Re: [swift-evolution] Symmetrical operators

Well, I dont actually think it can be considered as a syntax sugar. It requires creating separate function to achieve same effect. This is all about how operators behave in general. > 14 нояб. 2016 г., в 12:51, Anton Zhilin написал(а): > > -1 > Not worth adding

Re: [swift-evolution] Symmetrical operators

Отправлено с iPhone > 14 нояб. 2016 г., в 12:51, Anton Zhilin написал(а): > > -1 > Not worth adding syntactic sugar for a narrow use case. Plus it's an additive > feature. ___ swift-evolution mailing list

Re: [swift-evolution] Symmetrical operators

I'm a +1 on the feature, though for simply handling symmetry it's not a super critical issue. I wonder though, when you start looking at symmetry is it worth looking at other patterns? For example, could symmetrical operators be covered by a broader multi-part operator definition? I was

Re: [swift-evolution] Symmetrical operators

+1 I think the use cases are not that sparse actually. I would also argue that it would be easier to understand the intent of the code with some sort of keyword than with a hard copy of each function. > On 14 Nov 2016, at 10:51, Anton Zhilin via swift-evolution >

Re: [swift-evolution] Symmetrical operators

-1 Not worth adding syntactic sugar for a narrow use case. Plus it's an additive feature. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Selector for current method

On 14 Nov 2016, at 01:01, Robert Widmann wrote: > > NSSelectorFromString(#function) works just fine for this already. Hi Robert, it doesn’t work. NSSelectorFromString(#function) … returns "contentsOfDirectory(at:includingPropertiesForKeys:options:)"

Re: [swift-evolution] [Proposal] Type Narrowing

> On 13 Nov 2016, at 16:16, Jean-Daniel via swift-evolution > wrote: > >> >> Le 13 nov. 2016 à 03:37, Dennis Lysenko via swift-evolution >> > a écrit : >> >> That's a good point in Jay's example and from

Re: [swift-evolution] Symmetrical operators

+1 Not symmetrical by default, but able to add an attribute/keyword to auto-generate a default implementation which swaps the lhs & rhs. > Hi, list! > > I’m thinking about proposal that would add a possibility to save some time on > creating symmetrical binary operators. > > The latest code