Re: [swift-evolution] Forums for swift.org workgroup: looking for volunteers

I’m also up for it! > On 16 Nov 2017, at 00:39, Nicole Jacque via swift-evolution > wrote: > > As Ted Kremenek has previously announced, we are in the process of moving the > Swift mailing lists to Discourse. Previously the discussion was mostly about > moving

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

> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution > a écrit : > > My opinion is that filterMap is the right choice of name. > > I'm completely biased, given that I already have a Swift library that uses > filterMap, in exactly this context, for a

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 14, 2017, at 11:29 PM, Chris Lattner via swift-evolution > wrote: > > extension PyVal { > subscript(dynamicMember member: String) -> PyVal { > get { > let result = PyObject_GetAttrString(borrowedPyObject, member)! > return PyRef(owned:

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

> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution > a écrit : > > On the topic of a method that "compacts" without also mapping... I think this > encourages poor designs that should be using lazy transformations instead of > aggregate processing. There

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

My opinion is that filterMap is the right choice of name. I'm completely biased, given that I already have a Swift library that uses filterMap, in exactly this context, for a Reactive Programming library:

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 15, 2017, at 8:35 PM, Paul Cantrell via swift-evolution > wrote: > > Q: Is there any special handling for that member name string — to handle ruby > method names like `blank?`, for example? > > A: This should be the job of a language-specific interop layer.

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

Interesting! I like the spirit of this proposal a lot. One question: presumably this behaves like Ruby’s method_missing in that any natively implemented members shadow the dynamic ones? i.e. Swift looks for a static match first, then uses the dynamicMember only as a fallback? I found myself

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

On Nov 15, 2017, at 1:38 AM, Andrew Thompson via swift-evolution wrote: > Hi Chris, > > There are only a few examples in the proposal that demonstrate using dynamic > member lookup. > > I suppose that some examples will look like this: > > let foo: PyRef = ... >

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

I'll argue in favor of names which include the term "some". "The Optional type is an enumeration with two cases. Optional.none is equivalent to the nil literal. Optional.some(Wrapped) stores a wrapped value." (https://developer.apple.com/documentation/swift/optional) let things = ["apple", nil,

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

Given the existence of filter already, I submit that filterMap is somewhat overloaded and users would expect that, like flatMap, it would map over all elements and then filter based on some predicate. While that’s awkward to express and likely isn’t useful enough to be in the standard

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

> On Nov 15, 2017, at 9:16 PM, Greg Parker wrote: > > >> On Nov 15, 2017, at 5:53 PM, John McCall > > wrote: >> >>> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution >>>

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

Without commenting on anything else, I have encountered one use-case where it would be nice to be able to “call” an instance. And that is, while modeling some mathematics, I made a DifferentiableFunction type which stores a function and optionally a reference to another DifferentiableFunction (its

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

On Wed, Nov 15, 2017 at 8:05 PM, Wallacy via swift-evolution < swift-evolution@swift.org> wrote: > “unwrappingMap”(or some variations using unwrap). > I’d like to propose “mapAndUnwrap”. It does what it says on the tin: map a sequence (into an optional type), then unwrap the values which

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

> On Nov 15, 2017, at 5:53 PM, John McCall wrote: > >> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution >> > wrote: >> >>> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution >>>

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

> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution > wrote: > >> >> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution >> > wrote: >> >>> On Nov 15, 2017, at 3:05 PM, Tino Heth via

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

I vote for “mapNonNil”, “mapDroppingNil” or “unwrappingMap”(or some variations using unwrap). It’s not pretty, but does the job! Em qua, 15 de nov de 2017 às 22:36, Greg Parker via swift-evolution < swift-evolution@swift.org> escreveu: > On Nov 15, 2017, at 2:31 PM, BJ Homer via

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

Having watched this discussion without much opinion before, I’ve found the argument about the meaning of map in a functional context to be somewhat convincing. While Swift isn’t a pure functional language, I think having the concept of a `map` generally mean a 1:1 mapping between input

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

> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution > wrote: > >> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution >> > wrote: >> >> Odd… exactly that is the reason why I think filterMap

Re: [swift-evolution] [swift-dev] Forums for swift.org workgroup: looking for volunteers

Great, I’ve responded to you both off-list! > On Nov 15, 2017, at 4:09 PM, Kelvin Ma via swift-evolution > wrote: > > im willing to help! > > On Wed, Nov 15, 2017 at 6:01 PM, Wallacy via swift-evolution >

Re: [swift-evolution] [swift-dev] Forums for swift.org workgroup: looking for volunteers

im willing to help! On Wed, Nov 15, 2017 at 6:01 PM, Wallacy via swift-evolution < swift-evolution@swift.org> wrote: > I will be on vacation after December 1, so I will have some time to help > if needed. > Em qua, 15 de nov de 2017 às 21:39, Nicole Jacque via swift-dev < > swift-...@swift.org>

Re: [swift-evolution] [swift-dev] Forums for swift.org workgroup: looking for volunteers

I will be on vacation after December 1, so I will have some time to help if needed. Em qua, 15 de nov de 2017 às 21:39, Nicole Jacque via swift-dev < swift-...@swift.org> escreveu: > As Ted Kremenek has previously announced, we are in the process of moving > the Swift mailing lists to Discourse.

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

I'd like to show my support for mapSome. It's clear, concise and to the point. It's the best name from all the alternatives IMHO > On Nov 15, 2017, at 7:15 PM, Ben Cohen via swift-evolution > wrote: > > I continue to favour mapSome, since it’s both literally and

[swift-evolution] Forums for swift.org workgroup: looking for volunteers

As Ted Kremenek has previously announced, we are in the process of moving the Swift mailing lists to Discourse. Previously the discussion was mostly about moving swift-evolution over to a forum, but the consensus from Ted and the Core Team was that should look to move all the lists to Discourse

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

On Nov 15, 2017, at 2:52 PM, Jean-Daniel via swift-evolution wrote: > Just a question about what it mean for API resilience. Actually, adding a > property to an existing class is not a breaking change. > > For a class that implements that protocol, as it will be

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 15, 2017, at 1:12 PM, Nathan Gray via swift-evolution > wrote: > > How would this work for a property access that caused a python exception to > be thrown? Are we assuming that only "good" non-throwing properties will be > bridged in this way? > > ``` >

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

Just a question about what it mean for API resilience. Actually, adding a property to an existing class is not a breaking change. For a class that implements that protocol, as it will be possible to use property accessor with any non existing property. Adding a new property to this class

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

> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution > wrote: > > Odd… exactly that is the reason why I think filterMap is the worst choice: > > Both are established terms of art, but one has a meaning that doesn’t fit to > the operation. > Applying filter

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

> I’m happy that the rename was accepted. I’d like to support renaming it to > filterMap because it uses two terms of art already pre-existing and > understood by the Swift community Odd… exactly that is the reason why I think filterMap is the worst choice: Both are established terms of art,

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

> On Nov 15, 2017, at 4:15 PM, David Hart via swift-evolution > wrote: > > I’m very much against a term like compactMap because it uses the term compact > which has no precedence in Swift’s Standard Library. I don’t really care what the name ends up being (as long

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

> On Nov 14, 2017, at 19:57, Hooman Mehr wrote: > > You can support all styles with enum as well. My point is precisely that perhaps we should not. While the switch-over-result style is neither better nor worse than the try-catch style, having both in one body of code isn’t

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

I understand the sentiment, but the language has so much sugar over Optional that I wouldn’t be surprised if even seasoned developers didn't know the name of Optional’s cases. > On 15 Nov 2017, at 22:15, Ben Cohen via swift-evolution > wrote: > > I continue to

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

> On 15 Nov 2017, at 21:55, John McCall via swift-evolution > wrote: > > Hello, Swift Community! > > The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" ran through > yesterday, November 14th, 2017. The proposal is available here: > >

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

I continue to favour mapSome, since it’s both literally and figuratively what it does, but appreciate that exposing the name of the Optional.some case isn’t to everyone’s taste. > On Nov 15, 2017, at 12:55 PM, John McCall via swift-evolution > wrote: > > Hello,

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

How would this work for a property access that caused a python exception to be thrown? Are we assuming that only "good" non-throwing properties will be bridged in this way? ``` >>> x = "hello" >>> x.foobar Traceback (most recent call last): File "", line 1, in AttributeError: 'str' object has

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

Hello, Swift Community! The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" ran through yesterday, November 14th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

Really interesting proposal, I don't really have the need for Python interop at the moment so I would be more interesting on the potential usages of this changes to improve Swift code like the proxy and json accessors that you mention. The JSON part I can see it, as you are basically accessing

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

"In functional programming, “map” must preserve structure (the container shape should stay the same), and “flatMap” must use the same structure throughout, including the return value of the higher order function it takes." I was gonna write the same, completely agree with that. I know Swift is

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 12, 2017, at 7:47 PM, Alejandro Alonso wrote: > > Sorry I’ve been gone for a while, I had to do a lot of traveling. > > 1. Initially I made this thinking that developers had the power to determine > their own lower bound. The current implementation uses the

Re: [swift-evolution] [Proposal] Random Unification

> On Nov 13, 2017, at 7:38 PM, Xiaodi Wu wrote: > > On Mon, Nov 13, 2017 at 7:12 PM, Alejandro Alonso > wrote: > After thinking about this for a while, I don’t agree with with an associated > type on

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

Thanks for this, Brent, you make a strong case! I didn't include a change to Collection.Index simply because it doesn't look like missing the constraint is really causing harm, just inconvenience. That said, you’re right that making something Hashable is easier than ever, and if we’re going to

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

I think we understand each other; we just disagree. If you believe that it makes intuitive sense to talk about “flattening” a sequence of optionals, then the current name perhaps makes sense. If you don’t think so, then the “flatten” name is awkward in this context. I don’t think most Swift

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

Looks like I finally have to draw on drawings... (hope the pictures aren’t considered inappropriate content ;-) But after all, it might be the best way to convey my point anyways: I’m not thinking in terms of type names (why should it only be possible to flatten a „Sequence“? Many people

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

Hej Rick, i definitely agree with you. +1 From my personal experience i can say that a good working language interoperability gives us tons of new possibilities. A big thing i like is that i could for example use already written projects in different languages which are maybe already in

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

+1 to both proposals. I don't know enough to comment further, but I know this would help in the adoption of Swift on my team(s) (we call a lot of Python, although currently via exec-ing some bash scripts; it's a mess, but works well in the CLI world the stuff was written for). > On Nov 14,

[swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

Hi Chris, There are only a few examples in the proposal that demonstrate using dynamic member lookup. I suppose that some examples will look like this: let foo: PyRef = ... foo.bar // translates into foo[dynamic: “bar”] foo.bar.baz // translates into foo[dynamic: “bar”][dynamic: “baz”] and if

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

~Robert Widmann 2017/11/14 22:02、Matthew Johnson via swift-evolution のメール: > > > Sent from my iPhone > >> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution >> wrote: >> >> Having read all the arguments for what to add