Re: [swift-evolution] Adding Result to the Standard Library

> On Nov 6, 2017, at 4:13 AM, Jon Shier > wrote: > > This consideration is further complicated by the possible addition of > typed throws in the future. However, the most commonly suggested > implementation fo typed throws keeps the ability

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

> On Nov 2, 2017, at 4:39 AM, Richard Wei wrote: >> Question though: how does it work? Say the first np.array call threw a >> python exception: >> >>> try Python.do { >>> let a = np.array([1, 2, 3]) >>> let b = np.array([[2], [4]]) >>> print(a.dot(b))

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

> On Nov 7, 2017, at 5:54 PM, Dave DeLong via swift-evolution > wrote: > > Hi Swift-Evolution, > > The Standard Library's goal is to be small and targeted. However, many > aspects of Apple-provided frameworks need or offer opportunities for > improvement or

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

> On Nov 8, 2017, at 12:08 PM, Kelvin Ma wrote: > > > > On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution > > wrote: > > >> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution >>

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

These are some really interesting analogies. How would you imagine the community “governance” of these “plugins” (which I assume would be libraries or packages) to be managed? What does it mean for the “full community” to manage them, and provide the rough guarantees you suggest? I like the

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> What is your evaluation of the proposal? Strong approve. I would happily also accept name variants such as mapFilter — but I’m heartily in favor of _something_ that distinguishes _by name_ flattening sequences vs. filtering nils. > Is the problem being addressed significant enough to

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

I find more limiting the ability not to declare @objc a property of a class that doesn't inherit from NSObject: class Foo { var x: Int = 0 } class Bar { var foo = Foo() // Why shouldn't we allow this @objc? } or protocol BarProtocol: AnyObject { func fooDidBar(_ foo:

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

Although there are historical architectures where the addressable space exceeds the word size, IIUC, we'd be saying that collections don't support more elements than there are addressable units in memory. Are there very many use cases where a collection needs to have more elements than that? I

[swift-evolution] [Review] SE-188 Make stdlib index types Hashable

Hello, Swift community! The review of “SE-0188: Make stdlib index types Hashable” begins now and runs through November 14th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0187: Introduce Sequence.filterMap(_:)

+1 for filterMap(_:) On Wed, Nov 8, 2017 at 7:35 PM, Johannes Weiß via swift-evolution < swift-evolution@swift.org> wrote: > +1 and agree with Stephen on why > > > On 8 Nov 2017, at 8:17 am, Stephen Celis via swift-evolution < > swift-evolution@swift.org> wrote: > > > > +1 > > > >> On Nov 7,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0187: Introduce Sequence.filterMap(_:)

+1 and agree with Stephen on why > On 8 Nov 2017, at 8:17 am, Stephen Celis via swift-evolution > wrote: > > +1 > >> On Nov 7, 2017, at 6:23 PM, John McCall wrote: >> >> • What is your evaluation of the proposal? > > BJ summarized my

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

> On 30 Oct 2017, at 6:16 am, Ted Kremenek via swift-evolution > wrote: > > A complementary tactic would be that migration tool support to Swift 5 would > insert the needed casts to NSString. That way even if the magic lookup is > gone in Swift 5 the code could be

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Wed, Nov 8, 2017, at 02:29 PM, Max Moiseev via swift-evolution wrote:> > >> On Nov 8, 2017, at 12:20 PM, Tino Heth <2...@gmx.de> wrote: >> >> >>> This is a wonderful example! But it’s an argument for a different >>> discussion (of general usefulness of implicit optional promotion). >>>

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 8, 2017, at 12:20 PM, Tino Heth <2...@gmx.de> wrote: > > >> This is a wonderful example! But it’s an argument for a different discussion >> (of general usefulness of implicit optional promotion). Thanks to the >> optional promotion, what the closure returns is not nil, but instead

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Kevin, I really like your reasoning about avoiding the code churn, and finding a better way to flag something to avoid optional hoisting. I think its better solution to the problem. It also has the added benefit of kicking out to map() and getting a slightly optimised version of the same

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

I guess I am mildly +1. I can’t think of a case where this wouldn’t be some sort of Integer, but I am also open to arguments against. I am not sure what the utility of having a type for this besides Int is... Thanks, Jon > On Nov 8, 2017, at 1:37 PM, Ben Cohen via swift-evolution >

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 3:23 PM, John McCall via swift-evolution > wrote: > > When writing your review, here are some questions you might want to answer in > your review: > > • What is your evaluation of the proposal? -1. I am indifferent on the name, but

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 3:35 PM, Kevin Ballard via swift-evolution > wrote: > > It's a fairly minor issue, one that really only affects new Swift programmers > anyway rather than all users > I’ve seen enough misuse of flatMap at this point to be confident saying

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

+1 it seems like a generic type just for the sake of it. Many languages do without a specific type for distance and use Int and it is a better solution because it is simpler. -- Howard. > On 9 Nov 2017, at 8:37 am, Ben Cohen via swift-evolution > wrote: > > > Hi

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

> On Nov 8, 2017, at 1:55 PM, Ben Cohen wrote: > > Apologies to Nate Cook, from whom this important came. I would love to pretend my accidentally a word there was a joke. But it wasn’t… ___ swift-evolution mailing list

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

> On Nov 8, 2017, at 1:37 PM, Ben Cohen via swift-evolution > wrote: > > This turns any problem of writing a generic collection algorithm into both a > collection _and_ > problem. Gah, typo. That should read “This turns any problem of writing a generic collection

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 4:23 PM, John McCall via swift-evolution > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md > > >

[swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

Hi Swift Evolution, A pitch for review, aimed at simplifying generic Collection algorithms. Online copy here: https://github.com/airspeedswift/swift-evolution/blob/5d1ffda2e83f5b95a88d5ce3948c5fd0d59622f4/proposals/-eliminate-indexdistance.md

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> Am 08.11.2017 um 21:25 schrieb John McCall : > >> My point is: The proposed filterMap isn’t a combination of map and filter at >> all — or can you build it just out of map & filter, like flatMap is >> constructed from map & flatten? > > You can built it out of map and

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

Hi Jon, An interesting proposal. I see value in an external markdown-formatted document to compliment our Swift code, but currently I already do this when discussing ideas or architecture and just call it “.md”. I agree with Erica on the point though that documentation with code is actually

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

I agree with Jon that conflating docs with code makes an otherwise clean swift file into a bit of a mess, and it discourages me slightly from properly documenting. If there was something akin to "extension" but for adding documentation from a separate file ("doc Class {...}"), that could be

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 8, 2017, at 3:20 PM, Tino Heth via swift-evolution > wrote: >> This is a wonderful example! But it’s an argument for a different discussion >> (of general usefulness of implicit optional promotion). Thanks to the >> optional promotion, what the closure

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> This is a wonderful example! But it’s an argument for a different discussion > (of general usefulness of implicit optional promotion). Thanks to the > optional promotion, what the closure returns is not nil, but instead is > .some(nil), and that is not filtered out. My point is: The proposed

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution < >

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Wed, Nov 8, 2017, at 11:28 AM, Max Moiseev wrote: > > >> On Nov 7, 2017, at 3:34 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:>> >> On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift- >> evolution wrote: >>

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

Em qua, 8 de nov de 2017 às 17:58, Ted Kremenek escreveu: > > On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution < > swift-evolution@swift.org> wrote: > > I do not

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution > wrote: > > > >> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution >> > wrote: >> >> I do not agree with Ted that only a few

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 8, 2017, at 11:49 AM, Riley Testut via swift-evolution > wrote: > > Hi Swift-Evolution, > > Back when SE-0057 > (https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md) > was proposed, it included the following

[swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

Hi Swift-Evolution, Back when SE-0057 (https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md) was proposed, it included the following passage: The generic type parameters in Swift will always be class-bound, i.e., the generic class will have the

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 5:23 PM, Tino Heth via swift-evolution > wrote: > > -1 > > I guess breaking existing code will be the show stopper for this proposal — > but I generally think that compatibility is a poor rationale to stop an > improvement, so my personal

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution > wrote: > > I do not agree with Ted that only a few projects should be ranked, everyone, > as it is in npm should be available. Only be graded according to > recommendations. > I’m a bit confused. I’m

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

On Nov 8, 2017, at 4:54 AM, Karl Wagner > wrote: >> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution >> > wrote: >> >> FWIW, Ben Cohen and I have been talking about

Re: [swift-evolution] continuations - "extensions on steroids" idea

I haven’t seen real resistance against partial types so far — and why should somebody oppose? Hopefully, no one who doesn’t like this feature will be forced to use it, right? But imho that’s a slippery path, because there’s still a cost associated with every feature that is completely new:

Re: [swift-evolution] continuations - "extensions on steroids" idea

My preference would be around features to aggregate functionality, or to provide proper mixing. 1. One simpler feature would be a way to indicate your implementation of a protocol is via a property, and that calls should be forwarded. 2. More complex mixin behavior would include the included

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 3:34 PM, Kevin Ballard via swift-evolution > wrote: > > On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote: >> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md >> >>

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

Colocation of docs with the material they document is valuable to me and I presume anyone updating code. If anything, it would be nice if Xcode provided a show/hide doc headers toggle though. -- E > On Nov 8, 2017, at 11:20 AM, Jon Gilbert via swift-evolution >

Re: [swift-evolution] continuations - "extensions on steroids" idea

That is a legitimate concern, but massive view controllers is a problem that already exists. The kind of person who would use partial classes to split up a giant view controller would probably also use extensions and just throw all of the fields in the main file. People do that today with both

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 8, 2017, at 1:20 PM, Kevin Ballard wrote: > > On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote: >> >>> On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution >>> > wrote: >>> >>> On Tue, Nov 7,

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> Am 08.11.2017 um 19:23 schrieb Kevin Ballard via swift-evolution > : > > On Tue, Nov 7, 2017, at 05:23 PM, Tino Heth via swift-evolution wrote: >> -1 >> >> I guess breaking existing code will be the show stopper for this proposal — >> but I generally think that

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Tue, Nov 7, 2017, at 05:23 PM, Tino Heth via swift-evolution wrote: > -1 > > I guess breaking existing code will be the show stopper for this > proposal — but I generally think that compatibility is a poor > rationale to stop an improvement, so my personal reasons are > different:> The name is

[swift-evolution] [Pitch] .swiftDoc files instead of inline docs

When I go to look at the actual source code of something, it’s almost always because: (a) the documentation was insufficient for me to really understand what’s going on, or (b) I already know what’s happening but I just want set a breakpoint for debugging. In both of these cases, the presence

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote: > >> On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:>> >> On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift- >> evolution wrote: >>

Re: [swift-evolution] async void

(I changed the subject since it’s not really the same topic) The short answer is that this code has the same problem even without async void: func sendMessage() { beginAsync { // … } } func onButtonClick() { sendMessage() showAlert("message sent") } If you want

Re: [swift-evolution] continuations - "extensions on steroids" idea

On 8 November 2017 at 15:56, Benjamin G wrote: > I'm extremely curious to know the use case that made you code this way. Is > it one of the case Adam listed before ? > > to "manage complexities". once the type is relatively big (it's not a view controller :) ->

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0187: Introduce Sequence.filterMap(_:)

+1 > On Nov 7, 2017, at 6:23 PM, John McCall wrote: > > • What is your evaluation of the proposal? BJ summarized my thoughts nicely. I think “flatMap” in its current form is confusing to both newcomers and functional programmers familiar with the nomenclature. I’ve

Re: [swift-evolution] continuations - "extensions on steroids" idea

I'm extremely curious to know the use case that made you code this way. Is it one of the case Adam listed before ? I don't want to sidetrack this issue, but i wonder if something like this https://golang.org/doc/effective_go.html#embedding wouldn't be a "cleaner" solution. On Wed, Nov 8, 2017 at

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

Huge +1 Dealing with path manipulations via Foundation is a real pain on Linux. I end up using a lot of C code from Glibc. And random support is another pain point. There are tons of uses for a non-std library, however, i would like to see python style imports (if possible) to avoid importing a

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

on Mon, 06 Nov 2017 14:33:44 -0800 Slava Pestov wrote: Hi all, > > Right now, the following two declarations are equivalent: > > struct S { > var x: Int? > } > > struct S { > var x: Int? = nil > } > > That is, mutable bindings of sugared optional type (but not Optional!) >

Re: [swift-evolution] continuations - "extensions on steroids" idea

On 8 November 2017 at 14:20, Mike Kluev wrote: > On 8 November 2017 at 10:54, Benjamin G > wrote: > >> All your use cases make perfect sense, however i see one potential issue >> with this "pattern" : >> >> I've seen a LOT of iOS developers

Re: [swift-evolution] continuations - "extensions on steroids" idea

On 8 November 2017 at 10:54, Benjamin G wrote: > All your use cases make perfect sense, however i see one potential issue > with this "pattern" : > > I've seen a LOT of iOS developers (some juniors, some not) ending up with > monstruous UIViewControllers, and it has

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution > > wrote: > > FWIW, Ben Cohen and I have been talking about possibly using Swift packages > as a way to seed out experimental ideas for extensions to the Standard >

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

@Félix Fischer Yes, I wanted to say central index. I chose the wrong term. Actually I could have summed it up like this: - Central Index - SwiftPM to download/search using this index like npm/nuget - GStreamer organization Style. I do not agree with Ted that only a few projects should be

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

This is a great idea. Enabling people to actually sell code could be game changing. On Wed, Nov 8, 2017 at 12:44 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > > On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > > We

Re: [swift-evolution] continuations - "extensions on steroids" idea

All your use cases make perfect sense, however i see one potential issue with this "pattern" : I've seen a LOT of iOS developers (some juniors, some not) ending up with monstruous UIViewControllers, and it has happened almost since the very beginning of iOS development. Because of their lack of

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> Would this attribute not be a form of deprecation? So far, I only encountered deprecation in the context of legacy functionality that will be removed later — but after taking a look in the dictionary, I think the word is actually a good fit (even if there are no plans to remove flatMap). >

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

Although I’m fine with the current behavior I’d go for the explicit init form. Swift promotes explicit value bindings avoiding surprises which I learnt to like. In Java private Optional var; field declaration without RHS simply gets inited with a null value and not the expected “none”. Really

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

> On Nov 7, 2017, at 11:22 PM, Howard Lovatt via swift-evolution > wrote: > > Not a big deal either way, but I prefer the 2nd (nil) form and therefore > would like to see the 1st form go. It would make Swift more consistent, > consider: > > let o: Int? // Looks