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

Proposal link: https://github.com/apple/swift-evolution/blob/master/ proposals/0188-stdlib-index-types-hashable.md • What is your evaluation of the proposal? +1 but would like it to further and require all index types to be Hashable. • Is the problem being addressed significant enough to

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

Glad to see people working on this! I already have a functioning almost-pure Swift PNG library , and a JPEG library is a month or two away. I’m glad someone is hacking away at some sort of rasterization engine (like cairo for

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

On Thu, Nov 9, 2017 at 12:37 PM, Wallacy via swift-evolution < swift-evolution@swift.org> wrote: > > > Em qui, 9 de nov de 2017 às 03:42, Ted Kremenek > escreveu: > >> These are some really interesting analogies. How would you imagine the >> community “governance” of these

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

+1 • What is your evaluation of the proposal? I am highly in favor of this proposal. I have seen so many of my peers struggle with custom types, like Result and Observable, that implement a functional flatMap as opposed to the aforementioned flatMap that I've seen create a barrier of learning.

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

> On Nov 9, 2017, at 4:29 AM, Xiaodi Wu wrote: > > Why not? Specifically, why shouldn't we require `Hashable` conformance on > indices? Adding it would require changes to conforming types, sure, but > indices are already required to be `Equatable`, and `Hashable`

Re: [swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

I really like this idea of scoped import, but I’m not sure it’s part of anything supported widely. I was about to suggest ‘namespaces’ but that’s not a thing in swift. On Nov 9, 2017, 17:06 -0500, Rod Brown , wrote: > > > On 7 Nov 2017, at 6:24 am, Tony Parker via

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

On the other side, I'd say requiring explicit initialization to nil increases the amount of busywork for the programmer for no good reason. I use it all the time and I would be pretty annoyed if it went away. I would be pretty shocked if most Swift users don't know that exists. On Mon, Nov 6,

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

> On Nov 9, 2017, at 1:48 PM, Ben Cohen via swift-evolution > > wrote: > >> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution >> > wrote: >> >> On Nov 9, 2017, at

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

> On Nov 9, 2017, at 4:01 PM, Paul Cantrell wrote: > > using the same name for both flatMap variants causes the type checker to > miss programmer errors Not to mention, makes it do a lot more work, lengthening compile times (especially when mixed with closure and

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

What I meant by flagging the renaming of the generic `flatMap` to the more specific-to-this-case `filterMap` is that all of the current uses of `flatMap` share conceptual details: they all process whatever is in the box, then perform one level of flattening. This shared concept is hugely

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

The idea is that renaming this will nudge people into using map when appropriate. > On Nov 9, 2017, at 1:45 PM, Jose Cheyo Jimenez via swift-evolution > wrote: > > - 1 I agree with Kevin Ballard. > > I think that it would be appropriate to nudge the user to use

Re: [swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

> On 7 Nov 2017, at 6:24 am, Tony Parker via swift-evolution > wrote: > > Hi Florent, > > We definitely thought about this while designing the set of types with the > Codable proposals. > > One serious concern was just how much API surface area there already is

Re: [swift-evolution] JSONEncoder: Key strategies

I’m a fan. I understand that the CodingKey was the initial thought behind how to customise this, but a transformative approach is nice where there is a patterned update to keys. Just one question: is there much performance impact by running through a key encoding strategy, even if it’s just a

Re: [swift-evolution] async void

> On Nov 9, 2017, at 11:02 AM, Wallacy wrote: > > So for me, this: > > func OnButtonClicked(_ sender:AnyObject) { > let button = sender as! UIButton > button.isEnabled = false > beginAsync { > await DoSomethingAsync() > button.isEnabled = true >

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

- 1 I agree with Kevin Ballard. I think that it would be appropriate to nudge the user to use map instead. We already nudge people to use let over var so I think is sensible to do the same for misuses of flatMap when map is sufficient. Thanks! > On Nov 8, 2017, at 10:43 AM, John McCall via

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

> On Nov 9, 2017, at 11:43 AM, Vladimir.S via swift-evolution > wrote: > > let a : [Int?] = [1,2,3,nil,4,nil,5] > > let b = a.flatMap { $0.flatMap{$0*10} } // current At the risk of taking us further down the rabbit hole… You really want: let b = a.flatMap {

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

> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution > wrote: > > On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution > > wrote: >> >> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell

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

On 09.11.2017 19:41, BJ Homer via swift-evolution wrote: On Nov 9, 2017, at 9:37 AM, Sam Warner via swift-evolution wrote: I accept the motivation for this change, although I would mention that: - in 2.5 years on a ~200k lines of Swift project - we've seen a

Re: [swift-evolution] update on forum

Glad to see there is progress on this :-) I am hoping, in addition to sections equivalent to the lists, there are areas for working groups on specific topics, and areas for 3rd party frameworks/packages to coordinate/cross-polinate ideas. For example, I have code which I use as a more

Re: [swift-evolution] async void

Before i make a comment on this topic i need to confirm something: On original proposal, this: func processImageData1(completionBlock: (result: Image) -> Void) { loadWebResource("dataprofile.txt") { dataResource in loadWebResource("imagedata.dat") { imageResource in

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

> The problem in the Doodads example is that the name flatMap is used to > identify two distinct intents: concatenating arrays and filtering nils. You may have read about my issues with the prefix, but following the same logic of „filtering nils“, the other variant of flatMap just filters out

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

On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution wrote: > > On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote: >> The problem in the Doodads example is that the name flatMap is used to >> identify two distinct intents:

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

> > On Nov 9, 2017, at 11:35 AM, Tino Heth <2...@gmx.de> wrote: > > >> This proposal only proposes renaming the “filterNonesAndMap” variant (though >> that name is misleading, it would be “filterNonesAfterMapping” if anything); >> the other uses of flatMap will remain unchanged. > … then it

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

Em qui, 9 de nov de 2017 às 03:42, Ted Kremenek escreveu: > 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? > Pretty much like a TV/Games/etc

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

On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:> The problem in the Doodads example is that *the name flatMap is used > to identify two distinct intents*: concatenating arrays and filtering > nils. One can argue that those two operations are, in some lofty > abstract

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

> This proposal only proposes renaming the “filterNonesAndMap” variant (though > that name is misleading, it would be “filterNonesAfterMapping” if anything); > the other uses of flatMap will remain unchanged. … then it should be really right: As I learned in the thread, there is a map step

Re: [swift-evolution] async void

Hi, I have two opinion about async void function, 1. I think async(or sync) function should has a returning value even if type is void. ``` let result = await somethingAsyncVoid() ``` In this case the `result` will available when `someThingAsyncVoid` was completed. Someone can omit it, but it

Re: [swift-evolution] JSONEncoder: Key strategies

Hi Brent, Perhaps the wording would be better phrased as "boundary from non-uppercase-character to uppercase-character", i.e. numbers and Emoji are treated the same as lowercase characters and are included in the original word. The following are [unit test cases from the associated

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

I have personally filed a few bugs on this; and I definitely consider it a bug that we cannot store Any in generics for objc. There are however some problem areas that might be worth considering while fixing this bug. 1) We need to ensure this does not cause source churn - I would expect swift

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

> On Nov 9, 2017, at 9:37 AM, Sam Warner via swift-evolution > wrote: > > I accept the motivation for this change, although I would mention that: > - in 2.5 years on a ~200k lines of Swift project > - we've seen a plenty of instances of `flatMap` used where `map`

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

I accept the motivation for this change, although I would mention that: - in 2.5 years on a ~200k lines of Swift project - we've seen a plenty of instances of `flatMap` used where `map` would have been sufficient, but - we've never burned time on tracking down the sort of compiler issue described

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 for throws to be untyped. >

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

On Nov 9, 2017, at 9:13 AM, Tino Heth via swift-evolution wrote: > > >> Experienced programmers (as experienced as any Swift programmer can be for a >> 4-year-old language) frequently use flatMap when they mean map > When you look at those examples: > What would

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

To those who pointed out that XCode can already fold comment blocks, let me point out that only works in XCode, and not in, say, github. If my pitch were implemented, your IDE could still show you the documentation inline with the code. In fact, XCode already lets you option-click a function

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

> On Nov 8, 2017, at 10:51 PM, Charlie Monroe via swift-evolution > wrote: > > 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

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

> Experienced programmers (as experienced as any Swift programmer can be for a > 4-year-old language) frequently use flatMap when they mean map When you look at those examples: What would stop those programmers to use filterMap in the exact same way, instead of switching to map? A hypothetic

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

They removed the little UI sidebar that was so useful for code folding, though. I do hope it makes a return. Also I am not saying projects should be forced to keep docs in separate files, just that it would be nice to have the option. I suppose it could be achieved through an XCode plugin

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

Sound great! Last week I started working on a pure-swift graphics library, one goal being fast server-side graphics manipulations, and already have .png decode/encode, and quadratic bezier curve stroking implemented, slowly, and poorly. I’m working on TrueType fonts right now, and intend to

Re: [swift-evolution] update on forum

I was thinking all the mailing lists. > On Nov 9, 2017, at 7:07 AM, Alejandro Martinez wrote: > > Thanks for the clarification on that Ted :) > Are all the mailing list gonna move there or only swift-evo? > > On Thu, Nov 9, 2017 at 2:13 PM, Ted Kremenek via swift-evolution

Re: [swift-evolution] update on forum

Thanks for the clarification on that Ted :) Are all the mailing list gonna move there or only swift-evo? On Thu, Nov 9, 2017 at 2:13 PM, Ted Kremenek via swift-evolution wrote: > The decision to move to a forum was announced a while ago, and it hasn’t > appeared yet.

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

> On Nov 8, 2017, at 11:49 PM, Chris Lattner via swift-evolution > wrote: > >> >> 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

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

I have started a new thread. > On Nov 9, 2017, at 2:05 AM, Adrian Zubarev > wrote: > > Hello Ted, would you mind opening a new thread and post an update about the > forum and maybe answer a few minor questions like: > - what is currently planned? > - in which

[swift-evolution] update on forum

The decision to move to a forum was announced a while ago, and it hasn’t appeared yet. I think we will be making the move soon and I wanted to provide some reasons why it was delayed and what comes next. The reasons it was delayed are twofold: - When we (the community) decided to move to a

Re: [swift-evolution] JSONEncoder: Key strategies

> On Nov 6, 2017, at 12:54 PM, Tony Parker via swift-evolution > wrote: > > Converting from camel case to snake case: > > 1. Splits words at the boundary of lower-case to upper-case > 2. Inserts `_` between words > 3. Lowercases the entire string > 4. Preserves

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

> On Oct 31, 2017, at 9:31 PM, Chris Lattner via swift-evolution > wrote: > > Since you bring it up, Python exceptions will be annoying - As with other > languages, Python can throw from an arbitrary expression. Modeling > everything as throws in Swift would be

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

Sent from my iPad > On Nov 9, 2017, at 6:29 AM, Xiaodi Wu via swift-evolution > wrote: > > >> On Thu, Nov 9, 2017 at 05:28 Brent Royal-Gordon via swift-evolution >> wrote: >> > >> >

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

On Thu, Nov 9, 2017 at 05:28 Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md > > > > • What is your evaluation of the proposal? > > This all seems very sensible, but

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

> On Nov 9, 2017, at 3:16 AM, Gwendal Roué via swift-evolution > wrote: > > I wish that the Swift-Evolution discussion around typed / untyped throws > would avoid three traps: > > - a bloodshed between pro and anti typed-throws > - a pro-typed-throws echo chamber

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

> • What is your evaluation of the proposal? „That’s not possible yet?“ ;-) > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. Conformance to Hashable might be useful in other areas besides key-paths, and even if not: The change shouldn’t do

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

> > https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md > > • What is your evaluation of the proposal? This all seems very sensible, but here's my big question: AnyIndex, which type erases any index type at run-time, would not be

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

> On 8 Nov 2017, at 18:57, Erica Sadun wrote: > > 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. [Xcode 9.1] Editor > Code Folding > Fold

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

> Le 9 nov. 2017 à 08:57, Chris Lattner via swift-evolution > a écrit : > > >> On Nov 6, 2017, at 4:13 AM, Jon Shier > > wrote: >> >> This consideration is further complicated by the possible addition of >> typed

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

Just to comment on the idea that a forum will pull the community together and improve this situation. A good and recent (as in young language) example of it is Rust https://users.rust-lang.org/c/announcements . You can filter by that category and see what the community is building, new libraries

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

Hello Ted, would you mind opening a new thread and post an update about the forum and maybe answer a few minor questions like: - what is currently planned? - in which timeframe we *might* see the forum finally happening (don’t have to be a promise)? - what happens to old mailing lists? (I’d say

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

i’m not one to applaud everything go does but its extended standard library seems nice On Thu, Nov 9, 2017 at 2:24 AM, Nick Keets via swift-evolution < swift-evolution@swift.org> wrote: > I think there are two ideas discussed in this thread at the same time. One > is for a more extended standard

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

On Thu, Nov 9, 2017 at 1:49 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 7, 2017, at 5:54 PM, Dave DeLong via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Hi Swift-Evolution, > > > > The Standard Library's goal is to be small and

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

On Thu, Nov 9, 2017 at 12:11 AM, Ted Kremenek wrote: > > > 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 < > swift-evolution@swift.org> wrote: > >> >> >> On Nov 8, 2017, at 11:40

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

I think there are two ideas discussed in this thread at the same time. One is for a more extended standard library, that is developed and shipped as part of the language. This is similar to what Python, Go and other languages are doing. The second is for a more wide collection of packages,