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

[David Hart via swift-evolution]

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 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 for 
> consistency.
> 
> I will be shepherding the transition from the mailing lists to the forum. 
> Rather than simply move the existing lists and structure as-is, we’d like to 
> take this opportunity to explore new ways of organizing the forums to help 
> foster communication and collaboration. We also have a number of new options 
> that will be available with Discourse, that we’d like some input from the 
> community on. 
> 
> To help with this, I am looking for 3-4 volunteers from the Swift community 
> to create a workgroup to discuss and create a plan for the structure for the 
> Discourse-based forums. We will then present this plan back to the community. 
> We are also investigating the possibility of having a preview version of the 
> forums available for comment from the community. 
> 
> If you would like to be part of this workgroup, please reply back to me and 
> let me know!
> 
> Thanks!
> Nicole 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gwendal Roué via swift-evolution]

> 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 Reactive Programming library:
> 
>   
> https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3
>  
> 

Another popular Reactive Programming Library uses filterMap with a different 
signature, and a different meaning: 
https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32

There are already different interpretations on "filter" in "filterMap" in the 
wild.

Gwendal Roué

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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: result)  // PyObject_GetAttrString returns +1 
> result.
> }
> set {
>   PyObject_SetAttrString(borrowedPyObject, member,
>  newValue.toPython().borrowedPyObject)
> }
>   }
> }

This looks great for Python, but let's talk about some other languages for a 
moment.

* Ruby and Perl don't have the "call a method by fetching a closure property 
and invoking it" behavior you're relying on here. Instead, Ruby has a syntax 
for settable "overloads" of methods (i.e. you can write `def someMember` and 
`def someMember= (newValue)`), while Perl supports lvalue methods (but 
sometimes uses getter and setter method pairs instead). How do you envision 
these behaviors being bridged to Swift? I worry that this protocol may not be 
sufficient, and that we may need a design which can distinguish between looking 
up methods and looking up properties.

* Ruby looks up members using symbols, which essentially play the same role as 
selectors in Objective-C—they're uniqued strings which are used for fast member 
dispatch. In some cases, you might see non-negligible speed improvements by 
only looking up the symbol once. Is there a way this design could accommodate 
that? For instance, could the type of the index be specified by an associated 
type, so Ruby could use a RbSymbol instead of a String? Or do you think that 
would be overkill?

* Generally, you've talked about properties (in this proposal) and methods (in 
the `DynamicCallable` proposal), but what about subscripts? Obviously you can 
just specify a `subscript(Pythonable) -> PyVal` on `PyVal` for the simple case, 
but what if the subscript takes multiple indices or has labels? Do we need a 
`DynamicSubscriptable` protocol?

* Let's step away from bridging entirely and just think about Swift for a 
moment. There are cases where we'd like to make *semi*-dynamic proxies which 
wrap another type and allow operations based on what's statically known about 
that type. Think, for example, of the appearance proxy in UIKit: This is an 
object attached to UIView subclasses which lets you (in essence) set default 
values for all instances. We currently just pretend it's an instance of `Self`, 
which mostly works because of Objective-C, but a Swift-native version would 
probably prefer to return a `UIAppearance` object which used its 
knowledge of `Self` to expose `Self`'s properties on itself. Is there a way we 
could design this feature, or a related feature, to cover that kind of use 
case? That is, to allow a limited set of keys—perhaps even key-path-based when 
you want static control—with a different type for each key, *or* to allow any 
key with some common type, depending on your type's needs?

* Actually, for that matter, let's talk about key paths. In principle, you can 
already think of member lookup in Swift—or at least property and subscript 
lookup—as though it always worked by constructing a key path and using 
`subscript(keyPath:)` to access it. Is there some way we could model this 
feature as extending the set of keys available on a given type—perhaps in a way 
that allowed compile-time-limited and strongly-typed sets of keys, like I 
mention with the `UIAppearance` example, in addition to the open-ended, 
type-erased sets you need—and then looking things up by key path? (Sorry if 
this is a little vague—I know very little about how key paths are implemented.)

* An implementation-level question about Swift: Internally, the compiler seems 
to be moving towards thinking of parameter labels as part of the identifier, 
rather than having them label the individual arguments. How do you see that 
jibing with what you're proposing here?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gwendal Roué via swift-evolution]

> 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 is almost always a way around a bare flatten. The 
> obvious quirkiness of `filterMap { $0 }` (or whatever the name ends up being) 
> should be seen as a nudge to re-think the algorithm leading up to that point.

I can hear the argument, but it errs in the side of premature optimization. 
Besides, seq.lazy.compacted() still has a meaning.

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matt Gallagher via swift-evolution]

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:


https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3

Obviously, I went through the thought process, looked at other libraries and 
thought it was the best name.

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 is almost always a way around a bare flatten. The 
obvious quirkiness of `filterMap { $0 }` (or whatever the name ends up being) 
should be seen as a nudge to re-think the algorithm leading up to that point.

Cheers,
Matt Gallagher.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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.

Swift has the backtick syntax for escaping keywords (`identifier`), but it 
doesn't allow non-identifier characters to be used in identifiers. We might 
explore loosening that.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gwendal Roué via swift-evolution]

Hello,

I cast my vote for compactMap. And I wish for another proposal for the plain 
non-mutating method `compacted`.

Some say that compact has no precedent in Swift, and is ambiguous.

"Compact" has no precedent because it names an operation which had no name yet: 
filtering out nils. Is is only as ambiguous as one resists mapping "compact" to 
"filter out nils".

Suggesting "compact" is suggesting that we acknowledge that filtering out nils 
is a very common operation which deserves its own name. Hence the wish for 
`array.compacted()` as a shorthand for `array.compactMap { $0 }`.

Suggesting "compact" is suggesting that we stop using the functional 
programming vocabulary for an operation that does not quite fit this model, as 
functional experts here have reminded several times.

"Compact" is not an attempt at piling up existing Swift words until they build 
"filtering out nils". That's three words. "Compact" elegantly compacts them all 
in a single word that is easy to learn, and remember.

"filterMap" forgets about nil checking. To support "filterMap", some claim that 
"filter" is OK because it means "reduce the size of an array". OK, but we are 
still missing "nils".

“unwrappingMap”, "mapAndUnwrap", "mapUnwrappingSome", "mapUnwrapSome", 
"mapUnwrapIfSome", and generally names around "unwrap": those are serious 
candidates. But what could be the natural shortening for `array.unwrappingMap { 
$0 }`? `array.unwrapped()`? What does it mean to "unwrap" a collection?

"mapSome" does not do what it claims: it maps, then keeps the some, instead of 
mapping the some.

"mapNonNil": same as above

"selectiveMap": it would be OK if "selecting" would be defined as "filtering 
out nils". Yet "compact" is better at this job, because "compacting" already, 
in English, means compressing by removing voids. "Selecting", in English, is a 
synonym for "filtering", and is less good as "compact", assuming we acknowledge 
introducing a new word in the Swift vocabulary for the "filtering out nils" 
operation.

“mapDroppingNil”, "mapStrippingNil" : now it's a matter of taste :-)

Gwendal Roué
Sorry for the not-so-compact reply

> 
> Le 15 nov. 2017 à 21:55, John McCall via swift-evolution 
>  a écrit :
> 
> 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
> 
> There was a significant amount of discussion, and people came down with 
> reasonable arguments both for and against the proposal.  After reviewing that 
> feedback, the core team feels that the central question is whether Swift 
> benefits from overloading flatMap in this way.  There is a reasonable 
> argument that an Optional is a sort of container, and therefore it makes 
> sense to "flatten" that container into a surrounding container.  But Swift 
> has resisted applying that interpretation in its library design; for example, 
> you cannot directly iterate an Optional or append its contents to an Array.  
> In general, we feel that using different operations for working with 
> Optionals tends to make code easier to both write and understand, especially 
> given the existence of implicit optional promotion, which we cannot eliminate 
> or easily suppress based on the context.  On reflection, we think it was a 
> mistake to use the same name in the first place, and there is no better time 
> to fix a mistake than now.
> 
> While we accept that this will cause some amount of "code churn" for 
> developers when they adopt Swift 5, the required change is a simple rename 
> that should be painless to automatically migrate.  Of course, sample code on 
> the internet will become obsolete, but fix-its will easily update that code 
> if pasted into a project, and the samples themselves (once corrected) should 
> become clearer and easier to teach after this change, as is generally true 
> when overloading is removed.
> 
> Accordingly, SE-0187 is accepted, at least as far as not calling the 
> operation "flatMap".  We are re-opening the review until next Monday, 
> November 20th, 2017, in order to have a focused discussion about the new 
> name.  Names that seemed to gain some traction in the first review include:
> 
>   - filterMap, which has precedent in existing functional languages, as well 
> as some popular Swift libraries, but which some people view as confusing
> 
>   - compactMap, which builds off the precedent of "compact" in Ruby
> 
> But please feel free to suggest a name other than these.
> 
> Reviews
> 
> Reviews are an important part of the Swift evolution process.  All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to me as the 
> review manager.  When replying, please try to keep the proposal

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

[Paul Cantrell via swift-evolution]

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 asking other questions as I read the proposal, and then agreeing 
with where you landed. Here are those questions in case they touch off useful 
thoughts:

• • •

Q: It seems like this fundamentally alters Swift’s aesthetic of “either an 
operation is type-safe, or it’s clear at the point of use that it’s not.” 
Should this use an operator other than a period, e.g. `pickle->loads(blob)`?

A: This shift in the language does give me pause, but using a different 
operator really undermines the interoperability story. This is probably a job 
for syntax highlighting, not syntax.

• • •

Q: Why the open-ended `associatedtype DynamicMemberLookupValue`? Seems like it 
will always just be Self in practice.

A: It would be Self in the Python and JSON examples in the proposal, but making 
it an associatedtype adds no implementation burden, does no apparent harm, and 
adds flexibility. Shifting types on traversal could be particularly useful in 
creating DSLs (e.g. sepia → Genus, sepia.officinalis → Species).

• • •

Q: OK, then shouldn’t individual dynamic methods be able to return different 
types?

A: And how precisely would that work?

Q: Good point. Question retracted.

• • •

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.

• • •

Q: Should the subscript also take arg types and/or labels to allow overloading?

A: Ruby, Python, and JS all resolve members by name alone, and leave it to 
functions to untangle their own args. Obj-C is the lone oddball here. Relying 
on the companion proposal to handle the args makes sense.

Cheers, P


> On Nov 15, 2017, at 1:29 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi All,
> 
> As a peer to the DynamicCallable proposal 
> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 
> ), I’d like 
> to get your feedback on making member lookup dynamically extensible.  My 
> primary motivation is to improve interoperability with dynamic languages like 
> Python, Perl, Ruby, Javascript, etc, but there are other use cases (e.g. when 
> working with untyped JSON).
> 
> In addition to being a high impact on expressivity of Swift, I believe an 
> implementation can be done in a way with changes that are localized, and thus 
> not have significant impact on the maintainability of the compiler as a 
> whole.  Once the pitch phase of this proposal helps refine the details, I’ll 
> be happy to prepare an implementation for consideration.
> 
> In case it is useful, I’m working on cleaning up my current prototype Python 
> bindings.  I’ll share them in the next day or two in case they are useful to 
> provide context.  It is amazingly simple: less than 500 lines of Swift code 
> (plus some small additional C header glue to work around clang importer 
> limitations) enables impressive interoperability.  The only problems are the 
> verbosity addressed by this proposal and the peer DynamicCallable proposal.
> 
> 
> Here is the canonical proposal URL:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
> 
> 
> A snapshot of the proposal is included below in case it is useful.  Thanks in 
> advance for help improving the proposal!
> 
> -Chris
> 
> 
> Introduce User-defined "Dynamic Member Lookup" Types
> 
> Proposal: SE- 
> 
> Author: Chris Lattner 
> Review Manager: TBD
> Status: Awaiting implementation
>  
> Introduction
> 
> This proposal introduces a new DynamicMemberLookupProtocol type to the 
> standard library. Types that conform to it provide "dot" syntax for arbitrary 
> names which are resolved at runtime. It is simple syntactic sugar which 
> allows the user to write:
> 
> a = someValue.someMember
> someValue.someMember = a
> and have it be interpreted by the compiler as:
> 
>   a = someValue[dynamicMember: "someMember"]
>   someValue[dynamicMember: "someMember"] = a
> Many other languages have analogous features (e.g. the composition of 
> Objective-C's explicit properties 
> 
>  and underlying messaging infrastructure 
> ).
>  This sort of functionality is great for implemen

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

[Alejandro Alonso via swift-evolution]

I wrote up a quick and dirty example displaying Randomizable in action working 
alongside Strideable 
https://gist.github.com/Azoy/30d2554d11a3fb8f770e3b310fb47aca . This example 
uses the 32 bit Unix timestamp to determine a Date’s range (0 … UInt32.max). 
Color’s range would obviously be 0 … 0xFF. As you can see from this 
example, Randomizable has the potential to provide massive functionality to 
types that are able to conform to it. Rust also implements a trait called Rand 
that achieves the same here https://doc.rust-lang.org/rand/rand/trait.Rand.html 
.

- Alejandro

On Nov 15, 2017, 11:43 AM -0600, Nate Cook , wrote:
On Nov 12, 2017, at 7:47 PM, Alejandro Alonso 
mailto:aalonso...@outlook.com>> 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 integer’s min value 
as a lower bound. If it makes sense to only allow unsigned integers from an 
RNG, then I’m perfectly fine with. I do disagree when you say that it should 
only generate UInt32s. The current approach allows, lets say mt19337 and 
mt19337-64, to be used within one generator. So if you wanted a UInt32, mt19337 
would be used, and if you asked for a UInt64, mt19337-64 would be used.

2. The Randomizable protocol isn’t always used with integers. Think Date.random 
or Color.random. These types of values are difficult to express with ranges. 
Randomizable solves this issue.

I don’t think these examples explain how the Randomizable protocol is useful. 
As currently proposed, types that are Randomizable can provide a random value, 
but the details of that are left up to the type, and vary widely. When you use 
.random on an integer type, you get any value between .min and .max, but on a 
floating-point type, it’s a value between 0.0 and 1.0. What would the range be 
when you use Date.random? What about Color.random?

Here’s an implementation using the Randomizable protocol as a constraint:

extension Array where Element: Randomizable {
init(randomElements: Int) {
self = (0..) {
self = (0.. Self {
  return range.random(using: generator)
 }
}

extension Randomizable where Self: BinaryFloatingPointer {
 public static func random(
  in range: {Closed}Range,
  using generator: RandomNumberGenerator
 ) -> Self {
  return range.random
 }
}

I think external types that wish to do something similar, like 
Data.random(bytes: 128), could extend Randomizable with their own custom needs. 
The stdlib would at this point provide all the features needed to make this 
happen very simply for something like Data.random(bytes: 128).

- Alejandro

On Nov 5, 2017, 10:44 PM -0600, Nate Cook 
mailto:natec...@apple.com>>, wrote:
Thanks for continuing to push this forward, Alejandro! I’m excited about the 
potential of having access to these APIs as part of the standard library. Here 
are a few comments on some different parts of the proposal:

1) For your RandomGenerator protocol, I’m not totally clear on the semantics of 
the next(_:) and next(_:upperBound:) methods. Do they both have zero as their 
lower bound, for example? I’m not sure it makes sense to have signed integers 
generated directly by an RNG—perhaps T: FixedWidthInteger & UnsignedInteger 
would be a more useful constraint. (Does it even need to be generic? What if 
RNGs just generate UInt32s?)

2) Can you say more about the purpose of the Randomizable protocol? How would 
we use that protocol in useful ways that we wouldn’t get from being able to 
select random values from ranges (half-open and closed) of FixedWidthInteger / 
BinaryFloatingPoint? My experience has been that a full-width random value is 
rarely what a user needs.

3) I agree with Xiaodi that Random should probably be a struct with a single 
shared instance, but I don’t think it should be internal. Hiding that shared 
RNG would make it hard for non-stdlib additions to have the same usage, as they 
would need to have completely separate implementations for the “default” and 
custom RNG versions.

4) I would also still suggest that the simplest version of random (that you use 
to get a value from a range or an element from a collection) should be a 
function, not a property. Collection properties like first, last, and count all 
represent facts that already exist about a collection, and don’t change unless 
the collection itself changes. Choosing a random element, on the other hand, is 
clearly going to be freshly performed on each call. In addition, with the 
notable exception of count, we try to ensure O(1) performance for properties, 
while random will be O(n) except in random-access collections. Finally, if it 
is a method, we can unify the two versions by providing a single method with 
the shared RNG as the default parameter.

5) To match the sorted() method, shuffled() should be on Sequence instead of 
Collection. I don’t think either shu

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

[Chris Lattner via swift-evolution]

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 = ...
> foo.bar // translates into foo[dynamic: “bar”]
> foo.bar.baz // translates into foo[dynamic: “bar”][dynamic: “baz”]
> 
> and if we have:
> 
> extension PyRef {
> var one: Int {
> return 1
> }
> }
> 
> foo.bar.one // returns 1, because it translates into foo[dynamic: “bar”].one
> 
> This to me is hinting that dynamic member lookup will only be applied to one 
> property at a time. In order for it to work on multiple levels, the type 
> being returned by the subscript operation must still conform to 
> DynamicMemberLookup. Is this how you envisioned it to work?

The author of the type gets to make that choice.  In the case of the Python 
interop, yes, it will return another PyRef.  In the case of a JSON library, 
that should also return "Self?" so that you can optional chain through an 
access path.

That said, there are other potential use cases where you may only want a single 
level of dynamism.  The proposal allows the API author to specify the element 
type, which means they have flexibility to do what is right for their usecase.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Ballard via swift-evolution]

On Wed, Nov 15, 2017, at 12:55 PM, 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:> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md>
>>  
> There was a significant amount of discussion, and people came down
> with reasonable arguments both for and against the proposal.  After
> reviewing that feedback, the core team feels that the central question
> is whether Swift benefits from overloading flatMap in this way.  There
> is a reasonable argument that an Optional is a sort of container, and
> therefore it makes sense to "flatten" that container into a
> surrounding container.  But Swift has resisted applying that
> interpretation in its library design; for example, you cannot directly
> iterate an Optional or append its contents to an Array.  In general,
> we feel that using different operations for working with Optionals
> tends to make code easier to both write and understand, especially
> given the existence of implicit optional promotion, which we cannot
> eliminate or easily suppress based on the context.  On reflection, we
> think it was a mistake to use the same name in the first place, and
> there is no better time to fix a mistake than now.> 
> While we accept that this will cause some amount of "code churn" for
> developers when they adopt Swift 5, the required change is a simple
> rename that should be painless to automatically migrate.  Of course,
> sample code on the internet will become obsolete, but fix-its will
> easily update that code if pasted into a project, and the samples
> themselves (once corrected) should become clearer and easier to teach
> after this change, as is generally true when overloading is removed.> 
> Accordingly, SE-0187 is *accepted*, at least as far as not calling the
> operation "flatMap".  We are re-opening the review until next Monday,
> November 20th, 2017, in order to have a focused discussion about the
> new name.  Names that seemed to gain some traction in the first review
> include:> 
>   - filterMap, which has precedent in existing functional languages,
> as well as some popular Swift libraries, but which some people
> view as confusing> 
>   - compactMap, which builds off the precedent of "compact" in Ruby
> 
> But please feel free to suggest a name other than these.
> 
> *Reviews*
> 
> Reviews are an important part of the Swift evolution process.  All
> reviews should be sent to the swift-evolution mailing list at> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to me as
> the review manager.  When replying, please try to keep the proposal
> link at the top of the message:> 
>> Proposal link:


>>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md>>
>>>  Reply text
>>> Other replies
> *What goes into a review?*
> 
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the
> direction of Swift.> 
> When writing your review, here are some questions you might want to
> answer in your review:> 
> • What is your evaluation of the proposal?

I'm not happy about the method being renamed, but if it must, I'm in
favor of filterMap. All the other suggestions I've seen are either weird
(e.g. "compact", which has no precedent in Swift or anything else I can
think of beyond Ruby), or potentially misleading (like mapSome, which
sounds like it takes a sequence of optionals and only modifies the non-
nil values).
-Kevin Ballard

> • Is the problem being addressed significant enough to warrant a
> change to Swift?> • Does this proposal fit well with the feel and direction 
> of Swift?
> • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?> • How much 
> effort did you put into your review? A glance, a quick
> reading, or an in-depth study?> 
> More information about the Swift evolution process is available at:
> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> As always, thank you for contributing to the evolution of Swift.
> 
> John McCall
> Review Manager
> _
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dylan Brown via swift-evolution]

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, "cat", "dog"]

print( things )
print( things.flatMap {$0} )

// Equivalently: apply map, filter for non-nil, and apply force unwrap.
func transform(x: Any?) -> Any? {return x}
print( things.map(transform).filter { $0 != nil }.map { $0! } )

for x in things {
  switch x {
  case .some:
print(x!)
  case .none:
break
  }
}

[Optional("apple"), nil, Optional("cat"), Optional("dog")]
> ["apple", "cat", "dog"]
> ["apple", "cat", "dog"]
> apple
> cat
> dog


Here's a variety of possible new names, in descending order of personal
preference:

mapUnwrappingSome
mapAndUnwrap  // Thanks Nevin, this is surprisingly clear.
mapUnwrapSome
mapUnwrapIfSome
mapSome   // For these last three, it's unclear when nil elements
are dropped. Before or after the map?
mapNonNil
mapStrippingNil

I'm opposed to filterMap. Combining the names of two commonly used methods
for this less frequent operation seems likely to cause as much confusion as
flatMap.
I'm opposed to compactMap. There are two English meanings of "compact", and
my initial thought was about enforcement of some kind of contract.
I think mapUnwrappingSome is explicit, puts clarity > brevity, and
maintains naming consistency within Swift. If the enumeration cases .some
and .none are taught along with Optionals, then this name is clear.

That's my 2-cents as a relatively inexperienced user.
-Dylan

On Wed, Nov 15, 2017 at 6:48 PM, Nevin Brackett-Rozinsky via
swift-evolution  wrote:

> 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 exist.
>
> Nevin
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jon Shier via swift-evolution]

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 library, to 
have it just handle nils would seem unexpected to anyone who hadn’t read the 
signature when finding it in the autocomplete list or reading in documentation. 
That why I like compact. It’s currently unused in Swift, so it can be given 
whatever meaning we want, and it coincides with Ruby’s use of it, meaning 
there’s at least some precedent for using it to remove nils.



Jon

> On Nov 15, 2017, at 9:58 PM, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> 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 
 mailto:swift-evolution@swift.org>> wrote:
 
> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
>> mailto:swift-evolution@swift.org>> 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 can remove elements, but it can never change types (I 
>> feel kind of silly to repeat this over and over, but so far, nobody took 
>> the time to falsify this).
> 
> The concern about filter changing types is only relevant if you think of 
> the filter applying to the result of the map, instead of being a part of 
> the filterMap operation itself (an operation that is distinct from map).
> 
> Let’s imagine that we had this instead:
> 
> enum SelectiveMapResult {
> case use(T)
> case ignore
> }
> 
> extension Sequence {
> func selectiveMap(_ selectiveTransform: 
> (Element)->SelectiveMapResult) -> [T]
> }
> 
> let actualNumbers =
> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
> (x)->SelectiveMapResult in
> if let value = Int(x) { return .use(value) }
> else { return .ignore }
> })
> 
> actualNumbers == [1, 2, 5]
> 
> The “selective” part of this operation doesn’t feel like it’s changing 
> the type of the result, because SelectiveMapResult is easily understood 
> to not be part of the mapping transformation; it just exists to tell us 
> whether we should use the result of that particular transformation. 
> Likewise, I don’t feel like the optional in filterMap is part of the 
> mapping operation; it’s just serving the same role as SelectiveMapResult. 
> (It should be obvious that SelectiveMapResult is just Optional with 
> another name here.)
 
 "selectiveMap" feels better in part due to grammar. "map" is obviously the 
 verb and "selective" is obviously a modification of "map". "selectiveMap" 
 is therefore performing some sort of special map operation. 
 
 "filterMap" feels bad for the same reason that "selectMap" would feel 
 worse than "selectiveMap". "filter" and "map" are both verbs in this 
 context. Grammatically the analogue to "selectiveMap" would be 
 "filteredMap" or "filteringMap". 
 
 But even then "filteredMap" or "filteringMap" is insufficient to describe 
 the operation. You additionally need to know that the "filter" here is not 
 ordinary "filter", but instead the special case "filter { $0 != nil }".
 
 
> The name filterMap focuses on removing the ignored values, as does 
> compactMap. The name selectiveMap focuses on retaining the non-ignored 
> values. I’m not sure whether focusing on the positive or negative aspects 
> is clearer here. I don’t particularly like the name compactMap, simply 
> because I don’t have a lot of experience with languages that use 
> “compact” to mean “drop the nil values”, and without that experience it 
> doesn’t seem intuitive. I think filterMap is better. But if we introduced 
> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
 
 Swift doesn't use "filter" to mean "drop the nil values" either. 
 
 
 "compactMap" is okay if "compact" is added. Is "compact" a common enough 
 operation in practice to pull its own weight?
 
 "mapSome" is great if you know about Optional.Some but terrible if you 
 don't. ("Okay, it maps some elements, but which ones?") 
 
 "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a 
 winner.
>>> 
>>> mapSome and especially mapNonNil both sound to me like they onl

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

[John McCall via swift-evolution]

> 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 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
> mailto:swift-evolution@swift.org>> 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 can remove elements, but it can never change types (I 
> feel kind of silly to repeat this over and over, but so far, nobody took 
> the time to falsify this).
 
 The concern about filter changing types is only relevant if you think of 
 the filter applying to the result of the map, instead of being a part of 
 the filterMap operation itself (an operation that is distinct from map).
 
 Let’s imagine that we had this instead:
 
 enum SelectiveMapResult {
 case use(T)
 case ignore
 }
 
 extension Sequence {
 func selectiveMap(_ selectiveTransform: 
 (Element)->SelectiveMapResult) -> [T]
 }
 
 let actualNumbers =
 ["1", "2", "apple", "banana", "5"].selectiveMap({ 
 (x)->SelectiveMapResult in
 if let value = Int(x) { return .use(value) }
 else { return .ignore }
 })
 
 actualNumbers == [1, 2, 5]
 
 The “selective” part of this operation doesn’t feel like it’s changing the 
 type of the result, because SelectiveMapResult is easily understood to not 
 be part of the mapping transformation; it just exists to tell us whether 
 we should use the result of that particular transformation. Likewise, I 
 don’t feel like the optional in filterMap is part of the mapping 
 operation; it’s just serving the same role as SelectiveMapResult. (It 
 should be obvious that SelectiveMapResult is just Optional with another 
 name here.)
>>> 
>>> "selectiveMap" feels better in part due to grammar. "map" is obviously the 
>>> verb and "selective" is obviously a modification of "map". "selectiveMap" 
>>> is therefore performing some sort of special map operation. 
>>> 
>>> "filterMap" feels bad for the same reason that "selectMap" would feel worse 
>>> than "selectiveMap". "filter" and "map" are both verbs in this context. 
>>> Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
>>> "filteringMap". 
>>> 
>>> But even then "filteredMap" or "filteringMap" is insufficient to describe 
>>> the operation. You additionally need to know that the "filter" here is not 
>>> ordinary "filter", but instead the special case "filter { $0 != nil }".
>>> 
>>> 
 The name filterMap focuses on removing the ignored values, as does 
 compactMap. The name selectiveMap focuses on retaining the non-ignored 
 values. I’m not sure whether focusing on the positive or negative aspects 
 is clearer here. I don’t particularly like the name compactMap, simply 
 because I don’t have a lot of experience with languages that use “compact” 
 to mean “drop the nil values”, and without that experience it doesn’t seem 
 intuitive. I think filterMap is better. But if we introduced 
 Sequence.compact() alongside .compactMap(), I’d probably get used to it.
>>> 
>>> Swift doesn't use "filter" to mean "drop the nil values" either. 
>>> 
>>> 
>>> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
>>> operation in practice to pull its own weight?
>>> 
>>> "mapSome" is great if you know about Optional.Some but terrible if you 
>>> don't. ("Okay, it maps some elements, but which ones?") 
>>> 
>>> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a 
>>> winner.
>> 
>> mapSome and especially mapNonNil both sound to me like they only map the 
>> non-nil values in the source sequence.
> 
> I thought it did map the non-nil values in the source sequence. Did I 
> misunderstand what the proposed filterMap does? It occurs to me that the 
> proposal does not have a standalone description of the filterMap operation.

func filterMap(_ f: (Element) -> T?) -> [T] {
  return self.map(f).filter { $0 != nil }.map( $0! } // not an efficient 
implementation
}

A mapping function is applied to all elements of the source sequence.  Unlike 
map, however, the mapping function can return nil, causing that value to be 
dropped from the result sequence.  Since the result sequence can therefore not 
contain any (directly) nil values, a level of optionality is removed from the 
result element type.  A common use case — perhaps the most common — is to 
simultaneously map and filter a sequence without introducing any unnecessary 
intermedia

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

[Nevin Brackett-Rozinsky via swift-evolution]

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 derivative).

I used the subscript notation for “calling” these DifferentiableFunctions,
because that’s what we have available, but it would certainly be nice to
use parentheses rather than square brackets.

Nevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nevin Brackett-Rozinsky via swift-evolution]

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 exist.

Nevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Greg Parker via swift-evolution]

> On Nov 15, 2017, at 5:53 PM, John McCall  wrote:
> 
>> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
 mailto:swift-evolution@swift.org>> 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 can remove elements, but it can never change types (I feel 
 kind of silly to repeat this over and over, but so far, nobody took the 
 time to falsify this).
>>> 
>>> The concern about filter changing types is only relevant if you think of 
>>> the filter applying to the result of the map, instead of being a part of 
>>> the filterMap operation itself (an operation that is distinct from map).
>>> 
>>> Let’s imagine that we had this instead:
>>> 
>>> enum SelectiveMapResult {
>>> case use(T)
>>> case ignore
>>> }
>>> 
>>> extension Sequence {
>>> func selectiveMap(_ selectiveTransform: 
>>> (Element)->SelectiveMapResult) -> [T]
>>> }
>>> 
>>> let actualNumbers =
>>> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
>>> (x)->SelectiveMapResult in
>>> if let value = Int(x) { return .use(value) }
>>> else { return .ignore }
>>> })
>>> 
>>> actualNumbers == [1, 2, 5]
>>> 
>>> The “selective” part of this operation doesn’t feel like it’s changing the 
>>> type of the result, because SelectiveMapResult is easily understood to not 
>>> be part of the mapping transformation; it just exists to tell us whether we 
>>> should use the result of that particular transformation. Likewise, I don’t 
>>> feel like the optional in filterMap is part of the mapping operation; it’s 
>>> just serving the same role as SelectiveMapResult. (It should be obvious 
>>> that SelectiveMapResult is just Optional with another name here.)
>> 
>> "selectiveMap" feels better in part due to grammar. "map" is obviously the 
>> verb and "selective" is obviously a modification of "map". "selectiveMap" is 
>> therefore performing some sort of special map operation. 
>> 
>> "filterMap" feels bad for the same reason that "selectMap" would feel worse 
>> than "selectiveMap". "filter" and "map" are both verbs in this context. 
>> Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
>> "filteringMap". 
>> 
>> But even then "filteredMap" or "filteringMap" is insufficient to describe 
>> the operation. You additionally need to know that the "filter" here is not 
>> ordinary "filter", but instead the special case "filter { $0 != nil }".
>> 
>> 
>>> The name filterMap focuses on removing the ignored values, as does 
>>> compactMap. The name selectiveMap focuses on retaining the non-ignored 
>>> values. I’m not sure whether focusing on the positive or negative aspects 
>>> is clearer here. I don’t particularly like the name compactMap, simply 
>>> because I don’t have a lot of experience with languages that use “compact” 
>>> to mean “drop the nil values”, and without that experience it doesn’t seem 
>>> intuitive. I think filterMap is better. But if we introduced 
>>> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
>> 
>> Swift doesn't use "filter" to mean "drop the nil values" either. 
>> 
>> 
>> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
>> operation in practice to pull its own weight?
>> 
>> "mapSome" is great if you know about Optional.Some but terrible if you 
>> don't. ("Okay, it maps some elements, but which ones?") 
>> 
>> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a 
>> winner.
> 
> mapSome and especially mapNonNil both sound to me like they only map the 
> non-nil values in the source sequence.

I thought it did map the non-nil values in the source sequence. Did I 
misunderstand what the proposed filterMap does? It occurs to me that the 
proposal does not have a standalone description of the filterMap operation.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
>>> mailto:swift-evolution@swift.org>> 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 can remove elements, but it can never change types (I feel 
>>> kind of silly to repeat this over and over, but so far, nobody took the 
>>> time to falsify this).
>> 
>> The concern about filter changing types is only relevant if you think of the 
>> filter applying to the result of the map, instead of being a part of the 
>> filterMap operation itself (an operation that is distinct from map).
>> 
>> Let’s imagine that we had this instead:
>> 
>> enum SelectiveMapResult {
>> case use(T)
>> case ignore
>> }
>> 
>> extension Sequence {
>> func selectiveMap(_ selectiveTransform: 
>> (Element)->SelectiveMapResult) -> [T]
>> }
>> 
>> let actualNumbers =
>> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
>> (x)->SelectiveMapResult in
>> if let value = Int(x) { return .use(value) }
>> else { return .ignore }
>> })
>> 
>> actualNumbers == [1, 2, 5]
>> 
>> The “selective” part of this operation doesn’t feel like it’s changing the 
>> type of the result, because SelectiveMapResult is easily understood to not 
>> be part of the mapping transformation; it just exists to tell us whether we 
>> should use the result of that particular transformation. Likewise, I don’t 
>> feel like the optional in filterMap is part of the mapping operation; it’s 
>> just serving the same role as SelectiveMapResult. (It should be obvious that 
>> SelectiveMapResult is just Optional with another name here.)
> 
> "selectiveMap" feels better in part due to grammar. "map" is obviously the 
> verb and "selective" is obviously a modification of "map". "selectiveMap" is 
> therefore performing some sort of special map operation. 
> 
> "filterMap" feels bad for the same reason that "selectMap" would feel worse 
> than "selectiveMap". "filter" and "map" are both verbs in this context. 
> Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
> "filteringMap". 
> 
> But even then "filteredMap" or "filteringMap" is insufficient to describe the 
> operation. You additionally need to know that the "filter" here is not 
> ordinary "filter", but instead the special case "filter { $0 != nil }".
> 
> 
>> The name filterMap focuses on removing the ignored values, as does 
>> compactMap. The name selectiveMap focuses on retaining the non-ignored 
>> values. I’m not sure whether focusing on the positive or negative aspects is 
>> clearer here. I don’t particularly like the name compactMap, simply because 
>> I don’t have a lot of experience with languages that use “compact” to mean 
>> “drop the nil values”, and without that experience it doesn’t seem 
>> intuitive. I think filterMap is better. But if we introduced 
>> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
> 
> Swift doesn't use "filter" to mean "drop the nil values" either. 
> 
> 
> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
> operation in practice to pull its own weight?
> 
> "mapSome" is great if you know about Optional.Some but terrible if you don't. 
> ("Okay, it maps some elements, but which ones?") 
> 
> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a winner.

mapSome and especially mapNonNil both sound to me like they only map the 
non-nil values in the source sequence.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Wallacy via swift-evolution]

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 swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution <
> swift-evolution@swift.org> 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 can remove elements, but it can never change types (I feel
> kind of silly to repeat this over and over, but so far, nobody took the
> time to falsify this).
>
>
> The concern about filter changing types is only relevant if you think of
> the filter applying to the *result* of the map, instead of being a part
> of the filterMap operation itself (an operation that is distinct from map
> ).
>
> Let’s imagine that we had this instead:
>
> enum SelectiveMapResult {
> case use(T)
> case ignore
> }
>
> extension Sequence {
> func selectiveMap(_ selectiveTransform: (Element)->
> SelectiveMapResult) -> [T]
> }
>
> let actualNumbers =
> ["1", "2", "apple", "banana", "5"].selectiveMap({ (x)->
> SelectiveMapResult in
> if let value = Int(x) { return .use(value) }
> else { return .ignore }
> })
>
> actualNumbers == [1, 2, 5]
>
>
> The “selective” part of this operation doesn’t feel like it’s changing the
> type of the result, because SelectiveMapResult is easily understood to
> not be part of the mapping transformation; it just exists to tell us
> whether we should *use the result* of that particular transformation.
> Likewise, I don’t feel like the optional in filterMap is part of the
> mapping operation; it’s just serving the same role as SelectiveMapResult.
> (It should be obvious that SelectiveMapResult is just Optional with
> another name here.)
>
>
> "selectiveMap" feels better in part due to grammar. "map" is obviously the
> verb and "selective" is obviously a modification of "map". "selectiveMap"
> is therefore performing some sort of special map operation.
>
> "filterMap" feels bad for the same reason that "selectMap" would feel
> worse than "selectiveMap". "filter" and "map" are both verbs in this
> context. Grammatically the analogue to "selectiveMap" would be
> "filteredMap" or "filteringMap".
>
> But even then "filteredMap" or "filteringMap" is insufficient to describe
> the operation. You additionally need to know that the "filter" here is not
> ordinary "filter", but instead the special case "filter { $0 != nil }".
>
>
> The name filterMap focuses on removing the ignored values, as does
> compactMap. The name selectiveMap focuses on retaining the non-ignored
> values. I’m not sure whether focusing on the positive or negative aspects
> is clearer here. I don’t particularly like the name compactMap, simply
> because I don’t have a lot of experience with languages that use “compact”
> to mean “drop the nil values”, and without that experience it doesn’t seem
> intuitive. I think filterMap is better. But if we introduced
> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
>
>
> Swift doesn't use "filter" to mean "drop the nil values" either.
>
>
> "compactMap" is okay if "compact" is added. Is "compact" a common enough
> operation in practice to pull its own weight?
>
> "mapSome" is great if you know about Optional.Some but terrible if you
> don't. ("Okay, it maps some elements, but which ones?")
>
> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a
> winner.
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jon Shier via swift-evolution]

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 and output to be 
a good bit of consistency when thinking about it abstractly. Therefore I think 
a new verb is necessary, so compact is my choice, similar to flatten. While it 
could be considered a very specific version of filter, I think that it can 
stand on its own, as it also unwraps. So compact() would compact any array of 
optionals and compactMap() would map and then compact. While that sort of map 
isn’t 1:1, it’s in the line of normal flatMap, where the transform may change 
the number of elements in the result beyond a simple flattening of the array.
As for popularity, personally I compact arrays of optionals far more 
than I flatten arrays of arrays. It’s especially useful in dealing with 
Objective-C types. 
Additionally, I think the logic I’ve just described justifies a 
flatten/flattened function to parallel flatMap. I know it would simplify my 
code, as I’m usually only flattening a single level of array without a 
transform.


Jon Shier

> 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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution 
>>> mailto:swift-evolution@swift.org>> 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 can remove elements, but it can never change types (I feel 
>>> kind of silly to repeat this over and over, but so far, nobody took the 
>>> time to falsify this).
>> 
>> The concern about filter changing types is only relevant if you think of the 
>> filter applying to the result of the map, instead of being a part of the 
>> filterMap operation itself (an operation that is distinct from map).
>> 
>> Let’s imagine that we had this instead:
>> 
>> enum SelectiveMapResult {
>> case use(T)
>> case ignore
>> }
>> 
>> extension Sequence {
>> func selectiveMap(_ selectiveTransform: 
>> (Element)->SelectiveMapResult) -> [T]
>> }
>> 
>> let actualNumbers =
>> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
>> (x)->SelectiveMapResult in
>> if let value = Int(x) { return .use(value) }
>> else { return .ignore }
>> })
>> 
>> actualNumbers == [1, 2, 5]
>> 
>> The “selective” part of this operation doesn’t feel like it’s changing the 
>> type of the result, because SelectiveMapResult is easily understood to not 
>> be part of the mapping transformation; it just exists to tell us whether we 
>> should use the result of that particular transformation. Likewise, I don’t 
>> feel like the optional in filterMap is part of the mapping operation; it’s 
>> just serving the same role as SelectiveMapResult. (It should be obvious that 
>> SelectiveMapResult is just Optional with another name here.)
> 
> "selectiveMap" feels better in part due to grammar. "map" is obviously the 
> verb and "selective" is obviously a modification of "map". "selectiveMap" is 
> therefore performing some sort of special map operation. 
> 
> "filterMap" feels bad for the same reason that "selectMap" would feel worse 
> than "selectiveMap". "filter" and "map" are both verbs in this context. 
> Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
> "filteringMap". 
> 
> But even then "filteredMap" or "filteringMap" is insufficient to describe the 
> operation. You additionally need to know that the "filter" here is not 
> ordinary "filter", but instead the special case "filter { $0 != nil }".
> 
> 
>> The name filterMap focuses on removing the ignored values, as does 
>> compactMap. The name selectiveMap focuses on retaining the non-ignored 
>> values. I’m not sure whether focusing on the positive or negative aspects is 
>> clearer here. I don’t particularly like the name compactMap, simply because 
>> I don’t have a lot of experience with languages that use “compact” to mean 
>> “drop the nil values”, and without that experience it doesn’t seem 
>> intuitive. I think filterMap is better. But if we introduced 
>> Sequence.compact() alongside .compactMap(), I’d probably get used to it.
> 
> Swift doesn't use "filter" to mean "drop the nil values" either. 
> 
> 
> "compactMap" is okay if "compact" is added. Is "compact" a common enough 
> operation in practice to pull its own weight?
> 
> "mapSome" is great if you know about Optional.Some but terrible if you don't. 
> ("Okay, it maps some elements, but which ones?") 
> 
> "mapNonNil" is obvious and ugly and perhaps its obviousness makes it a winner.
> 
> 
> -- 
> Greg Parker gpar...

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

[Greg Parker via swift-evolution]

> 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 
>> mailto:swift-evolution@swift.org>> 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 can remove elements, but it can never change types (I feel 
>> kind of silly to repeat this over and over, but so far, nobody took the time 
>> to falsify this).
> 
> The concern about filter changing types is only relevant if you think of the 
> filter applying to the result of the map, instead of being a part of the 
> filterMap operation itself (an operation that is distinct from map).
> 
> Let’s imagine that we had this instead:
> 
> enum SelectiveMapResult {
> case use(T)
> case ignore
> }
> 
> extension Sequence {
> func selectiveMap(_ selectiveTransform: 
> (Element)->SelectiveMapResult) -> [T]
> }
> 
> let actualNumbers =
> ["1", "2", "apple", "banana", "5"].selectiveMap({ 
> (x)->SelectiveMapResult in
> if let value = Int(x) { return .use(value) }
> else { return .ignore }
> })
> 
> actualNumbers == [1, 2, 5]
> 
> The “selective” part of this operation doesn’t feel like it’s changing the 
> type of the result, because SelectiveMapResult is easily understood to not be 
> part of the mapping transformation; it just exists to tell us whether we 
> should use the result of that particular transformation. Likewise, I don’t 
> feel like the optional in filterMap is part of the mapping operation; it’s 
> just serving the same role as SelectiveMapResult. (It should be obvious that 
> SelectiveMapResult is just Optional with another name here.)

"selectiveMap" feels better in part due to grammar. "map" is obviously the verb 
and "selective" is obviously a modification of "map". "selectiveMap" is 
therefore performing some sort of special map operation. 

"filterMap" feels bad for the same reason that "selectMap" would feel worse 
than "selectiveMap". "filter" and "map" are both verbs in this context. 
Grammatically the analogue to "selectiveMap" would be "filteredMap" or 
"filteringMap". 

But even then "filteredMap" or "filteringMap" is insufficient to describe the 
operation. You additionally need to know that the "filter" here is not ordinary 
"filter", but instead the special case "filter { $0 != nil }".


> The name filterMap focuses on removing the ignored values, as does 
> compactMap. The name selectiveMap focuses on retaining the non-ignored 
> values. I’m not sure whether focusing on the positive or negative aspects is 
> clearer here. I don’t particularly like the name compactMap, simply because I 
> don’t have a lot of experience with languages that use “compact” to mean 
> “drop the nil values”, and without that experience it doesn’t seem intuitive. 
> I think filterMap is better. But if we introduced Sequence.compact() 
> alongside .compactMap(), I’d probably get used to it.

Swift doesn't use "filter" to mean "drop the nil values" either. 


"compactMap" is okay if "compact" is added. Is "compact" a common enough 
operation in practice to pull its own weight?

"mapSome" is great if you know about Optional.Some but terrible if you don't. 
("Okay, it maps some elements, but which ones?") 

"mapNonNil" is obvious and ugly and perhaps its obviousness makes it a winner.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nicole Jacque via swift-evolution]

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 
> mailto: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 
> mailto:swift-...@swift.org>> escreveu:
> 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 for 
> consistency.
> 
> I will be shepherding the transition from the mailing lists to the forum. 
> Rather than simply move the existing lists and structure as-is, we’d like to 
> take this opportunity to explore new ways of organizing the forums to help 
> foster communication and collaboration. We also have a number of new options 
> that will be available with Discourse, that we’d like some input from the 
> community on.
> 
> To help with this, I am looking for 3-4 volunteers from the Swift community 
> to create a workgroup to discuss and create a plan for the structure for the 
> Discourse-based forums. We will then present this plan back to the community. 
> We are also investigating the possibility of having a preview version of the 
> forums available for comment from the community.
> 
> If you would like to be part of this workgroup, please reply back to me and 
> let me know!
> 
> Thanks!
> Nicole
> ___
> swift-dev mailing list
> swift-...@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kelvin Ma via swift-evolution]

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> escreveu:
>
>> 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
>> for consistency.
>>
>> I will be shepherding the transition from the mailing lists to the forum.
>> Rather than simply move the existing lists and structure as-is, we’d like
>> to take this opportunity to explore new ways of organizing the forums to
>> help foster communication and collaboration. We also have a number of new
>> options that will be available with Discourse, that we’d like some input
>> from the community on.
>>
>> To help with this, I am looking for 3-4 volunteers from the Swift
>> community to create a workgroup to discuss and create a plan for the
>> structure for the Discourse-based forums. We will then present this plan
>> back to the community. We are also investigating the possibility of having
>> a preview version of the forums available for comment from the community.
>>
>> If you would like to be part of this workgroup, please reply back to me
>> and let me know!
>>
>> Thanks!
>> Nicole
>> ___
>> swift-dev mailing list
>> swift-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Wallacy via swift-evolution]

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. 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
> for consistency.
>
> I will be shepherding the transition from the mailing lists to the forum.
> Rather than simply move the existing lists and structure as-is, we’d like
> to take this opportunity to explore new ways of organizing the forums to
> help foster communication and collaboration. We also have a number of new
> options that will be available with Discourse, that we’d like some input
> from the community on.
>
> To help with this, I am looking for 3-4 volunteers from the Swift
> community to create a workgroup to discuss and create a plan for the
> structure for the Discourse-based forums. We will then present this plan
> back to the community. We are also investigating the possibility of having
> a preview version of the forums available for comment from the community.
>
> If you would like to be part of this workgroup, please reply back to me
> and let me know!
>
> Thanks!
> Nicole
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Hugo Hennies via swift-evolution]

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 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, 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
>> 
>> There was a significant amount of discussion, and people came down with 
>> reasonable arguments both for and against the proposal.  After reviewing 
>> that feedback, the core team feels that the central question is whether 
>> Swift benefits from overloading flatMap in this way.  There is a reasonable 
>> argument that an Optional is a sort of container, and therefore it makes 
>> sense to "flatten" that container into a surrounding container.  But Swift 
>> has resisted applying that interpretation in its library design; for 
>> example, you cannot directly iterate an Optional or append its contents to 
>> an Array.  In general, we feel that using different operations for working 
>> with Optionals tends to make code easier to both write and understand, 
>> especially given the existence of implicit optional promotion, which we 
>> cannot eliminate or easily suppress based on the context.  On reflection, we 
>> think it was a mistake to use the same name in the first place, and there is 
>> no better time to fix a mistake than now.
>> 
>> While we accept that this will cause some amount of "code churn" for 
>> developers when they adopt Swift 5, the required change is a simple rename 
>> that should be painless to automatically migrate.  Of course, sample code on 
>> the internet will become obsolete, but fix-its will easily update that code 
>> if pasted into a project, and the samples themselves (once corrected) should 
>> become clearer and easier to teach after this change, as is generally true 
>> when overloading is removed.
>> 
>> Accordingly, SE-0187 is accepted, at least as far as not calling the 
>> operation "flatMap".  We are re-opening the review until next Monday, 
>> November 20th, 2017, in order to have a focused discussion about the new 
>> name.  Names that seemed to gain some traction in the first review include:
>> 
>>   - filterMap, which has precedent in existing functional languages, as well 
>> as some popular Swift libraries, but which some people view as confusing
>> 
>>   - compactMap, which builds off the precedent of "compact" in Ruby
>> 
>> But please feel free to suggest a name other than these.
>> 
>> Reviews
>> 
>> Reviews are an important part of the Swift evolution process.  All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to me as the 
>> review manager.  When replying, please try to keep the proposal link at the 
>> top of the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift.
>> 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>  • What is your evaluation of the proposal?
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  • Does this proposal fit well with the feel and direction of Swift?
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at:
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> As always, thank you for contributing to the evolution of Swift.
>> 
>> John McCall
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/sw

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

[Nicole Jacque via swift-evolution]

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 for consistency.

I will be shepherding the transition from the mailing lists to the forum. 
Rather than simply move the existing lists and structure as-is, we’d like to 
take this opportunity to explore new ways of organizing the forums to help 
foster communication and collaboration. We also have a number of new options 
that will be available with Discourse, that we’d like some input from the 
community on. 

To help with this, I am looking for 3-4 volunteers from the Swift community to 
create a workgroup to discuss and create a plan for the structure for the 
Discourse-based forums. We will then present this plan back to the community. 
We are also investigating the possibility of having a preview version of the 
forums available for comment from the community. 

If you would like to be part of this workgroup, please reply back to me and let 
me know!

Thanks!
Nicole 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

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 possible to use 
> property accessor with any non existing property. Adding a new property to 
> this class will now change the class behavior in unexpected way as the old 
> client will still call the dynamic lookup method, but new code will use the 
> new accessor method. Is it something that should be mention in the «  Effect 
> on API resilience » section ?

Right.  Sure, I’ll add a mention of that.

-Chris


> 
> 
>> Le 15 nov. 2017 à 08:29, Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> a écrit :
>> 
>> Hi All,
>> 
>> As a peer to the DynamicCallable proposal 
>> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 
>> ), I’d 
>> like to get your feedback on making member lookup dynamically extensible.  
>> My primary motivation is to improve interoperability with dynamic languages 
>> like Python, Perl, Ruby, Javascript, etc, but there are other use cases 
>> (e.g. when working with untyped JSON).
>> 
>> In addition to being a high impact on expressivity of Swift, I believe an 
>> implementation can be done in a way with changes that are localized, and 
>> thus not have significant impact on the maintainability of the compiler as a 
>> whole.  Once the pitch phase of this proposal helps refine the details, I’ll 
>> be happy to prepare an implementation for consideration.
>> 
>> In case it is useful, I’m working on cleaning up my current prototype Python 
>> bindings.  I’ll share them in the next day or two in case they are useful to 
>> provide context.  It is amazingly simple: less than 500 lines of Swift code 
>> (plus some small additional C header glue to work around clang importer 
>> limitations) enables impressive interoperability.  The only problems are the 
>> verbosity addressed by this proposal and the peer DynamicCallable proposal.
>> 
>> 
>> Here is the canonical proposal URL:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
>> 
>> 
>> A snapshot of the proposal is included below in case it is useful.  Thanks 
>> in advance for help improving the proposal!
>> 
>> -Chris
>> 
>> 
>> Introduce User-defined "Dynamic Member Lookup" Types
>> 
>> Proposal: SE- 
>> 
>> Author: Chris Lattner 
>> Review Manager: TBD
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> 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?
> 
> ```
> >>> x = "hello"
> >>> x.foobar
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'str' object has no attribute 'foobar'
> ```

The prototype that I’m working on (which I’ll send out at some point soon) 
defaults to assuming that calls, member lookups, etc are all non-throwing.  
There are multiple ways to model this, and I’m not super attached to this 
approach, but here is how the current prototype works:

If you’d like to write code that is throwing, a modifier is used to get it 
reflected as a Swift optional or error.  e.g.

let x : PyVal = “hello”
x.foobar  // traps.
x.checking.foobar // returns optional.

We could also use a postfix operator to make this nicer if common, e.g.:
x^.foobar

But I’d like to avoid that if at all possible.


The way this works is that there are two types, “PyVal” is the currency type 
for python values.  The “x.checking” invocation returns a “CheckedPyVal” 
wrapper around the PyVal.  Both PyVal and CheckedPyVal conform to the two 
Dynamic* protocols: the former traps on error, the later produces an optional 
or throws (for calls).

-Chris



> 
> 
> On Tue, Nov 14, 2017 at 11:29 PM, Chris Lattner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Hi All,
> 
> As a peer to the DynamicCallable proposal 
> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 
> ), I’d like 
> to get your feedback on making member lookup dynamically extensible.  My 
> primary motivation is to improve interoperability with dynamic languages like 
> Python, Perl, Ruby, Javascript, etc, but there are other use cases (e.g. when 
> working with untyped JSON).
> 
> In addition to being a high impact on expressivity of Swift, I believe an 
> implementation can be done in a way with changes that are localized, and thus 
> not have significant impact on the maintainability of the compiler as a 
> whole.  Once the pitch phase of this proposal helps refine the details, I’ll 
> be happy to prepare an implementation for consideration.
> 
> In case it is useful, I’m working on cleaning up my current prototype Python 
> bindings.  I’ll share them in the next day or two in case they are useful to 
> provide context.  It is amazingly simple: less than 500 lines of Swift code 
> (plus some small additional C header glue to work around clang importer 
> limitations) enables impressive interoperability.  The only problems are the 
> verbosity addressed by this proposal and the peer DynamicCallable proposal.
> 
> 
> Here is the canonical proposal URL:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
> 
> 
> A snapshot of the proposal is included below in case it is useful.  Thanks in 
> advance for help improving the proposal!
> 
> -Chris
> 
> 
> Introduce User-defined "Dynamic Member Lookup" Types
> 
> Proposal: SE- 
> 
> Author: Chris Lattner 
> Review Manager: TBD
> Status: Awaiting implementation
>  
> Introduction
> 
> This proposal introduces a new DynamicMemberLookupProtocol type to the 
> standard library. Types that conform to it provide "dot" syntax for arbitrary 
> names which are resolved at runtime. It is simple syntactic sugar which 
> allows the user to write:
> 
> a = someValue.someMember
> someValue.someMember = a
> and have it be interpreted by the compiler as:
> 
>   a = someValue[dynamicMember: "someMember"]
>   someValue[dynamicMember: "someMember"] = a
> Many other languages have analogous features (e.g. the composition of 
> Objective-C's explicit properties 
> 
>  and underlying messaging infrastructure 
> ).
>  This sort of functionality is great for implementing dynamic language 
> interoperability, dynamic proxy APIs 
> ,
>  and other APIs (e.g. for JSON processing).
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
>  and Context
> 
> Swift is well known for being e

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

[Jean-Daniel via swift-evolution]

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 will now change the class behavior in unexpected way as the old client 
will still call the dynamic lookup method, but new code will use the new 
accessor method. Is it something that should be mention in the «  Effect on API 
resilience » section ?


> Le 15 nov. 2017 à 08:29, Chris Lattner via swift-evolution 
>  a écrit :
> 
> Hi All,
> 
> As a peer to the DynamicCallable proposal 
> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 
> ), I’d like 
> to get your feedback on making member lookup dynamically extensible.  My 
> primary motivation is to improve interoperability with dynamic languages like 
> Python, Perl, Ruby, Javascript, etc, but there are other use cases (e.g. when 
> working with untyped JSON).
> 
> In addition to being a high impact on expressivity of Swift, I believe an 
> implementation can be done in a way with changes that are localized, and thus 
> not have significant impact on the maintainability of the compiler as a 
> whole.  Once the pitch phase of this proposal helps refine the details, I’ll 
> be happy to prepare an implementation for consideration.
> 
> In case it is useful, I’m working on cleaning up my current prototype Python 
> bindings.  I’ll share them in the next day or two in case they are useful to 
> provide context.  It is amazingly simple: less than 500 lines of Swift code 
> (plus some small additional C header glue to work around clang importer 
> limitations) enables impressive interoperability.  The only problems are the 
> verbosity addressed by this proposal and the peer DynamicCallable proposal.
> 
> 
> Here is the canonical proposal URL:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
> 
> 
> A snapshot of the proposal is included below in case it is useful.  Thanks in 
> advance for help improving the proposal!
> 
> -Chris
> 
> 
> Introduce User-defined "Dynamic Member Lookup" Types
> 
> Proposal: SE- 
> 
> Author: Chris Lattner 
> Review Manager: TBD

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[BJ Homer via swift-evolution]

> 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 can remove elements, but it can never change types (I feel 
> kind of silly to repeat this over and over, but so far, nobody took the time 
> to falsify this).

The concern about filter changing types is only relevant if you think of the 
filter applying to the result of the map, instead of being a part of the 
filterMap operation itself (an operation that is distinct from map).

Let’s imagine that we had this instead:

enum SelectiveMapResult {
case use(T)
case ignore
}

extension Sequence {
func selectiveMap(_ selectiveTransform: 
(Element)->SelectiveMapResult) -> [T]
}

let actualNumbers =
["1", "2", "apple", "banana", "5"].selectiveMap({ 
(x)->SelectiveMapResult in
if let value = Int(x) { return .use(value) }
else { return .ignore }
})

actualNumbers == [1, 2, 5]

The “selective” part of this operation doesn’t feel like it’s changing the type 
of the result, because SelectiveMapResult is easily understood to not be part 
of the mapping transformation; it just exists to tell us whether we should use 
the result of that particular transformation. Likewise, I don’t feel like the 
optional in filterMap is part of the mapping operation; it’s just serving the 
same role as SelectiveMapResult. (It should be obvious that SelectiveMapResult 
is just Optional with another name here.)

The name filterMap focuses on removing the ignored values, as does compactMap. 
The name selectiveMap focuses on retaining the non-ignored values. I’m not sure 
whether focusing on the positive or negative aspects is clearer here. I don’t 
particularly like the name compactMap, simply because I don’t have a lot of 
experience with languages that use “compact” to mean “drop the nil values”, and 
without that experience it doesn’t seem intuitive. I think filterMap is better. 
But if we introduced Sequence.compact() alongside .compactMap(), I’d probably 
get used to it.

-BJ


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

> 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, but one has a meaning that doesn’t fit to 
the operation.
Applying filter can remove elements, but it can never change types (I feel kind 
of silly to repeat this over and over, but so far, nobody took the time to 
falsify this).

So, I’d rather introduce a unburnt word than reuse an existing term that 
conveys a wrong message. Honestly, I’d consider „reduceMap“ less bad… but I 
can’t see any good reason to limit the choice to something that is already used 
in Swift — after all, we don’t have to pay for new names.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Stephen Celis via swift-evolution]

> 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 as it’s not 
“flatMap”), but you do bring up something worth addressing.

I imagine a majority of calls to this function are of the lines of “compactMap 
{ $0 }”, so maybe it’s worth adding a helper/alias like “compact()”?

Stephen
https://www.pointfree.co___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

Those two proposals are growing on me and they have the potential to make Swift 
even better at DSLs.

> On 15 Nov 2017, at 08:29, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi All,
> 
> As a peer to the DynamicCallable proposal 
> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 
> ), I’d like 
> to get your feedback on making member lookup dynamically extensible.  My 
> primary motivation is to improve interoperability with dynamic languages like 
> Python, Perl, Ruby, Javascript, etc, but there are other use cases (e.g. when 
> working with untyped JSON).
> 
> In addition to being a high impact on expressivity of Swift, I believe an 
> implementation can be done in a way with changes that are localized, and thus 
> not have significant impact on the maintainability of the compiler as a 
> whole.  Once the pitch phase of this proposal helps refine the details, I’ll 
> be happy to prepare an implementation for consideration.
> 
> In case it is useful, I’m working on cleaning up my current prototype Python 
> bindings.  I’ll share them in the next day or two in case they are useful to 
> provide context.  It is amazingly simple: less than 500 lines of Swift code 
> (plus some small additional C header glue to work around clang importer 
> limitations) enables impressive interoperability.  The only problems are the 
> verbosity addressed by this proposal and the peer DynamicCallable proposal.
> 
> 
> Here is the canonical proposal URL:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
> 
> 
> A snapshot of the proposal is included below in case it is useful.  Thanks in 
> advance for help improving the proposal!
> 
> -Chris
> 
> 
> Introduce User-defined "Dynamic Member Lookup" Types
> 
> Proposal: SE- 
> 
> Author: Chris Lattner 
> Review Manager: TBD
> Status: Awaiting implementation
>  
> Introduction
> 
> This proposal introduces a new DynamicMemberLookupProtocol type to the 
> standard library. Types that conform to it provide "dot" syntax for arbitrary 
> names which are resolved at runtime. It is simple syntactic sugar which 
> allows the user to write:
> 
> a = someValue.someMember
> someValue.someMember = a
> and have it be interpreted by the compiler as:
> 
>   a = someValue[dynamicMember: "someMember"]
>   someValue[dynamicMember: "someMember"] = a
> Many other languages have analogous features (e.g. the composition of 
> Objective-C's explicit properties 
> 
>  and underlying messaging infrastructure 
> ).
>  This sort of functionality is great for implementing dynamic language 
> interoperability, dynamic proxy APIs 
> ,
>  and other APIs (e.g. for JSON processing).
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
>  and Context
> 
> Swift is well known for being exceptional at interworking with existing C and 
> Objective-C APIs, but its support for calling APIs written in scripting 
> languages like Python, Perl, and Ruby is quite lacking.
> 
> C and Objective-C are integrated into Swift by expending a heroic amount of 
> effort into integrating Clang ASTs, remapping existing APIs in an attempt to 
> feel "Swifty", and by providing a large number of attributes and 
> customization points for changing the behavior of this integration when 
> writing an Objective-C header. The end result of this massive investment of 
> effort is that Swift provides a better experience when programming against 
> these legacy APIs than Objective-C itself did.
> 
> When considering the space of dynamic languages, three things are clear: 1) 
> there are several different languages of interest, and they each have 
> significant interest in different quarters: for example, Python is big in 
> data science and machine learning, Ruby is popular for building server side 
> apps, and even Perl is in still widely used. 2) These languages have decades 
> of library building behind them, sometimes with significant communities 
>  and 3) there are one or two orders of magnitude 
> more users of these libraries than there are people currently using Swift.
> 
> While it is theoretically possible to expend t

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

[Guillaume Lessard via swift-evolution]

> 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  pleasant. 

We can privilege the try-catch style and still get the benefits of Result.

Guillaume Lessard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

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 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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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
>>  
>> 
>> 
>> There was a significant amount of discussion, and people came down with 
>> reasonable arguments both for and against the proposal.  After reviewing 
>> that feedback, the core team feels that the central question is whether 
>> Swift benefits from overloading flatMap in this way.  There is a reasonable 
>> argument that an Optional is a sort of container, and therefore it makes 
>> sense to "flatten" that container into a surrounding container.  But Swift 
>> has resisted applying that interpretation in its library design; for 
>> example, you cannot directly iterate an Optional or append its contents to 
>> an Array.  In general, we feel that using different operations for working 
>> with Optionals tends to make code easier to both write and understand, 
>> especially given the existence of implicit optional promotion, which we 
>> cannot eliminate or easily suppress based on the context.  On reflection, we 
>> think it was a mistake to use the same name in the first place, and there is 
>> no better time to fix a mistake than now.
>> 
>> While we accept that this will cause some amount of "code churn" for 
>> developers when they adopt Swift 5, the required change is a simple rename 
>> that should be painless to automatically migrate.  Of course, sample code on 
>> the internet will become obsolete, but fix-its will easily update that code 
>> if pasted into a project, and the samples themselves (once corrected) should 
>> become clearer and easier to teach after this change, as is generally true 
>> when overloading is removed.
>> 
>> Accordingly, SE-0187 is accepted, at least as far as not calling the 
>> operation "flatMap".  We are re-opening the review until next Monday, 
>> November 20th, 2017, in order to have a focused discussion about the new 
>> name.  Names that seemed to gain some traction in the first review include:
>> 
>>   - filterMap, which has precedent in existing functional languages, as well 
>> as some popular Swift libraries, but which some people view as confusing
>> 
>>   - compactMap, which builds off the precedent of "compact" in Ruby
>> 
>> But please feel free to suggest a name other than these.
>> 
>> Reviews
>> 
>> Reviews are an important part of the Swift evolution process.  All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to me as the 
>> review manager.  When replying, please try to keep the proposal link at the 
>> top of the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>>  
>> 
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift.
>> 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>> 
>>  • What is your evaluation of the proposal?
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  • Does this proposal fit well with the feel and direction of Swift?
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at:
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> 
>> As always, thank you for contributing to the evolution of Swift.
>> 
>> John McCall
>> Review Manager
>> ___
>> swift-evolution mailing l

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

[David Hart via swift-evolution]

> 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:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>  
> 
> 
> There was a significant amount of discussion, and people came down with 
> reasonable arguments both for and against the proposal.  After reviewing that 
> feedback, the core team feels that the central question is whether Swift 
> benefits from overloading flatMap in this way.  There is a reasonable 
> argument that an Optional is a sort of container, and therefore it makes 
> sense to "flatten" that container into a surrounding container.  But Swift 
> has resisted applying that interpretation in its library design; for example, 
> you cannot directly iterate an Optional or append its contents to an Array.  
> In general, we feel that using different operations for working with 
> Optionals tends to make code easier to both write and understand, especially 
> given the existence of implicit optional promotion, which we cannot eliminate 
> or easily suppress based on the context.  On reflection, we think it was a 
> mistake to use the same name in the first place, and there is no better time 
> to fix a mistake than now.
> 
> While we accept that this will cause some amount of "code churn" for 
> developers when they adopt Swift 5, the required change is a simple rename 
> that should be painless to automatically migrate.  Of course, sample code on 
> the internet will become obsolete, but fix-its will easily update that code 
> if pasted into a project, and the samples themselves (once corrected) should 
> become clearer and easier to teach after this change, as is generally true 
> when overloading is removed.
> 
> Accordingly, SE-0187 is accepted, at least as far as not calling the 
> operation "flatMap".  We are re-opening the review until next Monday, 
> November 20th, 2017, in order to have a focused discussion about the new 
> name.  Names that seemed to gain some traction in the first review include:
> 
>   - filterMap, which has precedent in existing functional languages, as well 
> as some popular Swift libraries, but which some people view as confusing
> 
>   - compactMap, which builds off the precedent of "compact" in Ruby
> 
> But please feel free to suggest a name other than these.
> 
> Reviews
> 
> Reviews are an important part of the Swift evolution process.  All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to me as the 
> review manager.  When replying, please try to keep the proposal link at the 
> top of the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>  
> 
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift.
> 
> When writing your review, here are some questions you might want to answer in 
> your review:
> 
>   • What is your evaluation of the proposal?

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: map makes it clear it is an operation on a Sequence, 
while filter makes it clear that the resulting array may be smaller than 
original array.

I’m very much against a term like compactMap because it uses the term compact 
which has no precedence in Swift’s Standard Library.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Yes, but I think that comparing with other languages (like Ruby for compactMap) 
is not the right approach. We need to choose a name which feels at home in the 
Standard Library.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> As always, thank you for contributing to the evolution of Swift.
> 
> John McCall
> Rev

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

[Ben Cohen via swift-evolution]

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, 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
>  
> 
> 
> There was a significant amount of discussion, and people came down with 
> reasonable arguments both for and against the proposal.  After reviewing that 
> feedback, the core team feels that the central question is whether Swift 
> benefits from overloading flatMap in this way.  There is a reasonable 
> argument that an Optional is a sort of container, and therefore it makes 
> sense to "flatten" that container into a surrounding container.  But Swift 
> has resisted applying that interpretation in its library design; for example, 
> you cannot directly iterate an Optional or append its contents to an Array.  
> In general, we feel that using different operations for working with 
> Optionals tends to make code easier to both write and understand, especially 
> given the existence of implicit optional promotion, which we cannot eliminate 
> or easily suppress based on the context.  On reflection, we think it was a 
> mistake to use the same name in the first place, and there is no better time 
> to fix a mistake than now.
> 
> While we accept that this will cause some amount of "code churn" for 
> developers when they adopt Swift 5, the required change is a simple rename 
> that should be painless to automatically migrate.  Of course, sample code on 
> the internet will become obsolete, but fix-its will easily update that code 
> if pasted into a project, and the samples themselves (once corrected) should 
> become clearer and easier to teach after this change, as is generally true 
> when overloading is removed.
> 
> Accordingly, SE-0187 is accepted, at least as far as not calling the 
> operation "flatMap".  We are re-opening the review until next Monday, 
> November 20th, 2017, in order to have a focused discussion about the new 
> name.  Names that seemed to gain some traction in the first review include:
> 
>   - filterMap, which has precedent in existing functional languages, as well 
> as some popular Swift libraries, but which some people view as confusing
> 
>   - compactMap, which builds off the precedent of "compact" in Ruby
> 
> But please feel free to suggest a name other than these.
> 
> Reviews
> 
> Reviews are an important part of the Swift evolution process.  All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to me as the 
> review manager.  When replying, please try to keep the proposal link at the 
> top of the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>  
> 
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift.
> 
> When writing your review, here are some questions you might want to answer in 
> your review:
> 
>   • What is your evaluation of the proposal?
>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   • Does this proposal fit well with the feel and direction of Swift?
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> As always, thank you for contributing to the evolution of Swift.
> 
> John McCall
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nathan Gray via swift-evolution]

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 no attribute 'foobar'
```


On Tue, Nov 14, 2017 at 11:29 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi All,
>
> As a peer to the DynamicCallable proposal (https://gist.github.com/
> lattner/a6257f425f55fe39fd6ac7a2354d693d), I’d like to get your feedback
> on making member lookup dynamically extensible.  My primary motivation is
> to improve interoperability with dynamic languages like Python, Perl, Ruby,
> Javascript, etc, but there are other use cases (e.g. when working with
> untyped JSON).
>
> In addition to being a high impact on expressivity of Swift, I believe an
> implementation can be done in a way with changes that are localized, and
> thus not have significant impact on the maintainability of the compiler as
> a whole.  Once the pitch phase of this proposal helps refine the details,
> I’ll be happy to prepare an implementation for consideration.
>
> In case it is useful, I’m working on cleaning up my current prototype
> Python bindings.  I’ll share them in the next day or two in case they are
> useful to provide context.  It is amazingly simple: less than 500 lines of
> Swift code (plus some small additional C header glue to work around clang
> importer limitations) enables impressive interoperability.  The only
> problems are the verbosity addressed by this proposal and the peer
> DynamicCallable proposal.
>
>
> Here is the canonical proposal URL:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
>
> A snapshot of the proposal is included below in case it is useful.  Thanks
> in advance for help improving the proposal!
>
> -Chris
>
>
> Introduce User-defined "Dynamic Member Lookup" Types
>
>- Proposal: SE-
>
>- Author: Chris Lattner 
>- Review Manager: TBD
>- Status: Awaiting implementation
>
>
> 
> Introduction
>
> This proposal introduces a new DynamicMemberLookupProtocol type to the
> standard library. Types that conform to it provide "dot" syntax for
> arbitrary names which are resolved at runtime. It is simple syntactic sugar
> which allows the user to write:
>
> a = someValue.someMember
> someValue.someMember = a
>
> and have it be interpreted by the compiler as:
>
>   a = someValue[dynamicMember: "someMember"]
>   someValue[dynamicMember: "someMember"] = a
>
> Many other languages have analogous features (e.g. the composition of
> Objective-C's explicit properties
> 
>  and
> underlying messaging infrastructure
> ).
> This sort of functionality is great for implementing dynamic language
> interoperability, dynamic proxy APIs
> ,
> and other APIs (e.g. for JSON processing).
>
> Swift-evolution thread: Discussion thread topic for that proposal
> 
>
> Motivation
> and Context
>
> Swift is well known for being exceptional at interworking with existing C
> and Objective-C APIs, but its support for calling APIs written in scripting
> languages like Python, Perl, and Ruby is quite lacking.
>
> C and Objective-C are integrated into Swift by expending a heroic amount
> of effort into integrating Clang ASTs, remapping existing APIs in an
> attempt to feel "Swifty", and by providing a large number of attributes and
> customization points for changing the behavior of this integration when
> writing an Objective-C header. The end result of this massive investment of
> effort is that Swift provides a *better* experience when programming
> against these legacy APIs than Objective-C itself did.
>
> When considering the space of dynamic languages, three things are clear:
> 1) there are several different languages of interest, and they each have
> significant interest in different quarters: for example, Python is big in
> data science and machine learning, Ruby is popular for building server side
> apps, and even Perl is in still widely used. 2) These languages have
> decades of library building behind them, sometimes with significant
> communities  and 3) there are one or two
> orders of magnitude more users of these libraries than the

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

[John McCall via swift-evolution]

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
 


There was a significant amount of discussion, and people came down with 
reasonable arguments both for and against the proposal.  After reviewing that 
feedback, the core team feels that the central question is whether Swift 
benefits from overloading flatMap in this way.  There is a reasonable argument 
that an Optional is a sort of container, and therefore it makes sense to 
"flatten" that container into a surrounding container.  But Swift has resisted 
applying that interpretation in its library design; for example, you cannot 
directly iterate an Optional or append its contents to an Array.  In general, 
we feel that using different operations for working with Optionals tends to 
make code easier to both write and understand, especially given the existence 
of implicit optional promotion, which we cannot eliminate or easily suppress 
based on the context.  On reflection, we think it was a mistake to use the same 
name in the first place, and there is no better time to fix a mistake than now.

While we accept that this will cause some amount of "code churn" for developers 
when they adopt Swift 5, the required change is a simple rename that should be 
painless to automatically migrate.  Of course, sample code on the internet will 
become obsolete, but fix-its will easily update that code if pasted into a 
project, and the samples themselves (once corrected) should become clearer and 
easier to teach after this change, as is generally true when overloading is 
removed.

Accordingly, SE-0187 is accepted, at least as far as not calling the operation 
"flatMap".  We are re-opening the review until next Monday, November 20th, 
2017, in order to have a focused discussion about the new name.  Names that 
seemed to gain some traction in the first review include:

  - filterMap, which has precedent in existing functional languages, as well as 
some popular Swift libraries, but which some people view as confusing

  - compactMap, which builds off the precedent of "compact" in Ruby

But please feel free to suggest a name other than these.

Reviews

Reviews are an important part of the Swift evolution process.  All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to me as the 
review manager.  When replying, please try to keep the proposal link at the top 
of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
 

Reply text
Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift.

When writing your review, here are some questions you might want to answer in 
your review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change 
to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md 


As always, thank you for contributing to the evolution of Swift.

John McCall
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alejandro Martinez via swift-evolution]

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 with
strings a keyed data structure.
But I'm having a hard time imagining how a proxy example would work as
there doesn't seem to be a mechanism to access Swift members from the
information received on the subscript. I pressume you can call your
proxied object subscript but that would mean that the proxied objects
need to be also DynamicMemberLookupProtocol and in any case at some
point down the chain somebody will have to dispatch from the "string"
to a member lookup with some switch or similar.
Am I missing something or is this just completely unrelated to the
proposal and I just left my imagination go to far? :P

On Wed, Nov 15, 2017 at 10:58 AM, Stefan Mayer-Popp via
swift-evolution  wrote:
> 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 production and reuse their 
> proven functionality without the requirement to transform the code to Swift.
> The complexity of the Swift language itself isn't even touched in any area a 
> “casual” developer uses, i personally see no argument of not integrating this 
> feature for Swift.
>
> I for myself can see a lot new possibilities and more reasons (and better 
> arguments) for using Swift in other areas in my company like a normal phone 
> app or some command-line tools.
> Symbiosis is great lets have some fun with Swython, Swuby or SwHP in future.
>
> --
> Stefan Mayer-Popp
>
>
>
>> On 15. Nov 2017, at 11:08, Rick Mann via swift-evolution 
>>  wrote:
>>
>> +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, 2017, at 23:29 , Chris Lattner via swift-evolution 
>>>  wrote:
>>>
>>> Hi All,
>>>
>>> As a peer to the DynamicCallable proposal 
>>> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d), I’d 
>>> like to get your feedback on making member lookup dynamically extensible.  
>>> My primary motivation is to improve interoperability with dynamic languages 
>>> like Python, Perl, Ruby, Javascript, etc, but there are other use cases 
>>> (e.g. when working with untyped JSON).
>>>
>>> In addition to being a high impact on expressivity of Swift, I believe an 
>>> implementation can be done in a way with changes that are localized, and 
>>> thus not have significant impact on the maintainability of the compiler as 
>>> a whole.  Once the pitch phase of this proposal helps refine the details, 
>>> I’ll be happy to prepare an implementation for consideration.
>>>
>>> In case it is useful, I’m working on cleaning up my current prototype 
>>> Python bindings.  I’ll share them in the next day or two in case they are 
>>> useful to provide context.  It is amazingly simple: less than 500 lines of 
>>> Swift code (plus some small additional C header glue to work around clang 
>>> importer limitations) enables impressive interoperability.  The only 
>>> problems are the verbosity addressed by this proposal and the peer 
>>> DynamicCallable proposal.
>>>
>>>
>>> Here is the canonical proposal URL:
>>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
>>>
>>> A snapshot of the proposal is included below in case it is useful.  Thanks 
>>> in advance for help improving the proposal!
>>>
>>> -Chris
>>>
>>>
>>> Introduce User-defined "Dynamic Member Lookup" Types
>>>
>>>  • Proposal: SE-
>>>  • Author: Chris Lattner
>>>  • Review Manager: TBD
>>>  • Status: Awaiting implementation
>>> Introduction
>>>
>>> This proposal introduces a new DynamicMemberLookupProtocol type to the 
>>> standard library. Types that conform to it provide "dot" syntax for 
>>> arbitrary names which are resolved at runtime. It is simple syntactic sugar 
>>> which allows the user to write:
>>>
>>>a = someValue.someMember
>>>
>>>someValue.
>>> someMember = a
>>> and have it be interpreted by the compiler as:
>>>
>>>  a = someValue[dynamicMember: "someMember"
>>> ]
>>>  someValue[
>>> dynamicMember: "someMember"] = a
>>> Many other languages have analogous features (e.g. the composition of 
>>> Objective-C's explicit properties and underlying messaging infrastructure). 
>>> This sort of functionality is great for implementing dynamic language 
>>> interoperability, dynamic proxy APIs, and other APIs (e.g. for JSON 
>>> processing).
>>>
>>> Swift-evolution thread

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

[Alejandro Martinez via swift-evolution]

"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 not purely functional and that some don't really care
about functional names, but giving names to concepts is always good
for communication and that's the only reason why FP langs use specific
names for specific types and operations. Even if we don't really carea
bout that, and we just want to pick approachable names for newcomers
Swift already picked "flatMap" (and map, reduce, etc) so the least
think we could to is at least make the name apply to operations that
follow the proper rules.

On Wed, Nov 15, 2017 at 8:16 PM, Stephen Celis via swift-evolution
 wrote:
> On Nov 15, 2017, at 10:39 AM, Tino Heth via swift-evolution
>  wrote:
>
> So conceptionally, both overrides are equivalent: The transformation always
> produces something — an Optional, and that can contain a value, or it can be
> empty, just like an array.
> You also see that the flatten step really does what it says: It removes one
> layer of objects, and leaves a flush surface without gaps.
>
> So, that should really be my last word in this discussion — I won’t add an
> animation or start singing about Optionals ;-)
>
>
> Your logic makes sense but doesn’t account for where “flatMap” came from and
> the expectations of how “flatMap” should work.
>
> 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.
>
> map :: (a -> b) -> m a -> m b
> flatMap :: (a -> m b) -> m a -> m b
>
> You may argue that Swift isn’t really a functional language and doesn’t have
> to adhere to functional rules, but as long as it adopts functional
> nomenclature, it should do its best to behave with functional expectations.
> It’s actually impossible to write “flatMap” as written above against a
> protocol like Sequence because Swift lacks higher kinded types, but we can
> at least approximate the behavior that functional programmers expect by
> narrowing the scope of what’s appropriate to return from that higher order
> function, which is in this case a sequence (of which Optional is not).
>
> In fact, I’d rather make “flatMap” stricter by requiring that higher order
> function to return an Array! This of course would kill some ergonomics, but
> it’d at least make things easier to reason about when you always get an
> Array out the other side.
>
> Stephen
> https://www.pointfree.co
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Alejandro Martinez
http://alejandromp.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Stephen Celis via swift-evolution]

> On Nov 15, 2017, at 10:39 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> So conceptionally, both overrides are equivalent: The transformation always 
> produces something — an Optional, and that can contain a value, or it can be 
> empty, just like an array.
> You also see that the flatten step really does what it says: It removes one 
> layer of objects, and leaves a flush surface without gaps.
> 
> So, that should really be my last word in this discussion — I won’t add an 
> animation or start singing about Optionals ;-)


Your logic makes sense but doesn’t account for where “flatMap” came from and 
the expectations of how “flatMap” should work.

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.

map :: (a -> b) -> m a -> m b
flatMap :: (a -> m b) -> m a -> m b

You may argue that Swift isn’t really a functional language and doesn’t have to 
adhere to functional rules, but as long as it adopts functional nomenclature, 
it should do its best to behave with functional expectations. It’s actually 
impossible to write “flatMap” as written above against a protocol like Sequence 
because Swift lacks higher kinded types, but we can at least approximate the 
behavior that functional programmers expect by narrowing the scope of what’s 
appropriate to return from that higher order function, which is in this case a 
sequence (of which Optional is not).

In fact, I’d rather make “flatMap” stricter by requiring that higher order 
function to return an Array! This of course would kill some ergonomics, but 
it’d at least make things easier to reason about when you always get an Array 
out the other side.

Stephen
https://www.pointfree.co___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nate Cook via swift-evolution]

> 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 integer’s min 
> value as a lower bound. If it makes sense to only allow unsigned integers 
> from an RNG, then I’m perfectly fine with. I do disagree when you say that it 
> should only generate UInt32s. The current approach allows, lets say mt19337 
> and mt19337-64, to be used within one generator. So if you wanted a UInt32, 
> mt19337 would be used, and if you asked for a UInt64, mt19337-64 would be 
> used.
> 
> 2. The Randomizable protocol isn’t always used with integers. Think 
> Date.random or Color.random. These types of values are difficult to express 
> with ranges. Randomizable solves this issue.

I don’t think these examples explain how the Randomizable protocol is useful. 
As currently proposed, types that are Randomizable can provide a random value, 
but the details of that are left up to the type, and vary widely. When you use 
.random on an integer type, you get any value between .min and .max, but on a 
floating-point type, it’s a value between 0.0 and 1.0. What would the range be 
when you use Date.random? What about Color.random?

Here’s an implementation using the Randomizable protocol as a constraint:

extension Array where Element: Randomizable {
init(randomElements: Int) {
self = (0..) {
self = (0.. 3. I’ve made the adjustment necessary for this.
> 
> 4. So while I can see your point for this, it would break the consistency 
> with Randomizable’s random property. You could argue that we could make this 
> property a function itself, but I think most will agree that Int.random is a 
> cleaner api than Int.random(). 
> 
> 5. I’ve made the adjustment necessary for this.
> 
> 6. I actually forgot to implement the random api for the ranges where Bound: 
> BinaryFloatingPoint. While implementing this, I realized these would never 
> fail and would always return a non-optional. So, I decided making the other 
> Countable ranges non-optional. (0 ..< 10).random would return a non-optional, 
> (0.0 ..< 10.0).random would return a non-optional, and Array(0 ..< 10).random 
> would return an optional. I can agree that something like (0 ..< 10).random 
> is hard to discover, so I added Int.random(in: 0 ..< 10) (along with 
> BinaryFloatingPoint). However, these are not requirements of Randomizable. I 
> think these methods would benefit more if they were extension methods:
> 
> extension Randomizable where Self: FixedWidthInteger, Self.Stride: 
> SignedInteger {
>  public static func random(
>   in range: Countable{Closed}Range,
>   using generator: RandomNumberGenerator
>  ) -> Self {
>   return range.random(using: generator)
>  }
> }
> 
> extension Randomizable where Self: BinaryFloatingPointer {
>  public static func random(
>   in range: {Closed}Range,
>   using generator: RandomNumberGenerator
>  ) -> Self {
>   return range.random
>  }
> }
> 
> I think external types that wish to do something similar, like 
> Data.random(bytes: 128), could extend Randomizable with their own custom 
> needs. The stdlib would at this point provide all the features needed to make 
> this happen very simply for something like Data.random(bytes: 128).
> 
> - Alejandro
> 
> On Nov 5, 2017, 10:44 PM -0600, Nate Cook , wrote:
>> Thanks for continuing to push this forward, Alejandro! I’m excited about the 
>> potential of having access to these APIs as part of the standard library. 
>> Here are a few comments on some different parts of the proposal:
>> 
>> 1) For your RandomGenerator protocol, I’m not totally clear on the semantics 
>> of the next(_:) and next(_:upperBound:) methods. Do they both have zero as 
>> their lower bound, for example? I’m not sure it makes sense to have signed 
>> integers generated directly by an RNG—perhaps T: FixedWidthInteger & 
>> UnsignedInteger would be a more useful constraint. (Does it even need to be 
>> generic? What if RNGs just generate UInt32s?)
>> 
>> 2) Can you say more about the purpose of the Randomizable protocol? How 
>> would we use that protocol in useful ways that we wouldn’t get from being 
>> able to select random values from ranges (half-open and closed) of 
>> FixedWidthInteger / BinaryFloatingPoint? My experience has been that a 
>> full-width random value is rarely what a user needs.
>> 
>> 3) I agree with Xiaodi that Random should probably be a struct with a single 
>> shared instance, but I don’t think it should be internal. Hiding that shared 
>> RNG would make it hard for non-stdlib additions to have the same usage, as 
>> they would need to have completely separate implementations for the 
>> “default” and custom RNG versions.
>> 
>> 4) I would also still suggest that the simplest version of random (that you 
>> use to get a value from a range or an eleme

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

[Nate Cook via swift-evolution]

> 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 RandomNumberGenerator. I think a generic FixedWidthInteger & 
> UnsignedInteger should be sufficient. If there were an associated type, and 
> the default for Random was UInt32, then there might be some arguments about 
> allowing Double to utilize the full 64 bit precision. We could make Random32 
> and Random64, but I think people will ask why there isn’t a Random8 or 
> Random16 for those bit widths. The same could also be said that any 
> experienced developer would know that his PRNG would be switched if he asked 
> for 32 bit or 64 bit. 
> 
> I don't understand. Of course, Double would require 64 bits of randomness. It 
> would obtain this by calling `next()` as many times as necessary to obtain 
> the requisite number of bits.
> 
> At base, any PRNG algorithm yields some fixed number of bits on each 
> iteration. You can certainly have a function that returns an arbitrary number 
> of random bits (in fact, I would recommend that such an algorithm be a 
> protocol extension method on RandomNumberGenerator), but it must be built on 
> top of a function that returns a fixed number of bits, where that number is 
> determined on a per-algorithm basis. Moreover--and this is 
> important--generating a random unsigned integer of arbitrary bit width in a 
> sound way is actually subtly _different_ from generating a floating-point 
> value of a certain bit width, and I'm not sure that one can be built on top 
> of the other. Compare, for example:
> 
> https://github.com/xwu/NumericAnnex/blob/c962760bf974a84ec57d8c5e94c91f06584e2453/Sources/PRNG.swift#L157
>  
> 
> https://github.com/xwu/NumericAnnex/blob/c962760bf974a84ec57d8c5e94c91f06584e2453/Sources/PRNG.swift#L316
>  
> 
> 
> (These are essentially Swift versions of C++ algorithms.)
> 
> Basically, what I'm saying is that RandomNumberGenerator needs a `next()` 
> method that returns a fixed number of bits, and extension methods that build 
> on that to return T : FixedWidthInteger & UnsignedInteger of arbitrary bit 
> width or U : BinaryFloatingPoint of an arbitrary number of bits of precision. 
> Each individual RNG does not need to reimplement the latter methods, just a 
> method to return a `next()` value of a fixed number of bits. You are welcome 
> to use my implementation.

An alternative to this is to have the random generator write a specified number 
of bytes to a pointer’s memory, as David Waite and others have suggested. This 
is same way arc4random_buf and SecRandomCopyBytes are implemented. Each random 
number generator could then choose the most efficient way to provide the 
requested number of bytes. The protocol could look something like this:

protocol RandomNumberGenerator {
/// Writes the specified number of bytes to the given pointer’s memory.
func read(into p: UnsafeMutableRawPointer, bytes: Int)
}

This is less user-friendly than having a next() method, but I think that’s a 
good thing—we very much want people who need a random value to use higher-level 
APIs and just pass the RNG as a parameter when necessary.

Nate


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nate Cook via swift-evolution]

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 make this change, 
the time is now.

I tried adding the constraint in a branch, and it isn't quite as simple as I 
had expected. For one thing, CountableRange and CountableClosedRange need the 
Bound type to be Hashable, not just Strideable, which increases the number of 
places that could be source breaking. You can see the full diff here:
https://github.com/apple/swift/pull/12944

Also complicating things is that I don’t know what the migration path would 
look like—we can’t use availability attributes on associated type constraints, 
so it could be very difficult to support compiling both existing Swift 4 code 
and code that works on a compiler that requires the Hashable constraint.

Nate

On Nov 9, 2017, at 7:12 PM, Brent Royal-Gordon via swift-evolution 
mailto:swift-evolution@swift.org>> wrote:

>> 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` conformance 
>> just got really easy to add, and custom `Collection`s are a relatively rare 
>> and advanced feature.
>> 
>> For a source-breaking change, that’s the wrong question to ask. It’s not 
>> “why not,” but “why so”? It’s so easy to add the conformance, and any type 
>> can opt into it so easily, what is the gain by forcing it and can it be 
>> justified as a source-breaking change?
> 
> 
> You're right that source-breaking changes need to be justified. What I would 
> say is:
> 
>   1. This proposal as written will require many conditional conformances; 
> it would be better (and would allow us to fully implement it sooner) if they 
> were unconditional.
> 
>   2. Relying on `where` clauses does not help you in type-erased code. 
> `AnyIndex` cannot conditionally conform to `Hashable` because it erases 
> types, and it's not clear to me whether `AnyIndex` can be cleanly converted 
> to `AnyHashable` or vice versa. This means code using type erasure may be 
> awkward to write if it needs `Hashable` indices.
> 
>   3. The `KeyPath` case discussed in this proposal is another example 
> where ad-hoc `Hashable` indices cause trouble for type erasure (in that 
> `KeyPath`s erase the types of the indices inside them). It would be very 
> weird for `KeyPath`s to only support indices if they happen to also be 
> `Hashable`.
> 
>   4. `Hashable` conformance is extremely useful in general. It allows, 
> among other features, use as a `Set` or `Dictionary` key, and apparently now 
> use in `KeyPath` as well. Replacing an `Array` of indices with a `Set`, or 
> switching from some other representation to a `KeyPath`, is the sort of 
> change we would like generic algorithms to be able to make without breaking 
> binary compatibility with their callers.
> 
>   5. `Hashable` occupies a special place of importance among our standard 
> protocols. In the past, we've occasionally discussed making it mandatory and 
> impossible to opt out of; many languages actually do that. Even though we 
> haven't, I've seen experts make flat statements along the lines of "All value 
> types should conform to `Hashable`". This is not like requiring an index to 
> be, say, `Strideable` or a `SignedInteger`.
> 
>   6. The compiler can now automatically synthesize `Hashable` conformance 
> for many simple types; this makes the burden of requiring a conformance 
> unusually low.
> 
>   7. I have written several custom collections, and it has never occurred 
> to me to conform the index to `Hashable`, but now that it's been mentioned I 
> realize that it would have been both easy and extremely useful to do so. My 
> index types would already have been `Hashable` if the standard library had 
> forced me to do so.
> 
> Basically, what it comes down to is, `Hashable` is very useful and there are 
> not many plausible index designs which would have trouble supporting it. It 
> is not absolutely necessary to make this change, but I think it would lead to 
> better, more useful types with a fairly low burden.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[BJ Homer via swift-evolution]

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 users would find it 
intuitive, as Optional does not conform to Sequence, and there is no 
ValueContainer protocol on which we might define “flatMap”. (And introducing 
such a protocol is outside the scope of this proposal.)

Even if “flatMap” does make conceptual sense to you on a sequence of Optionals, 
though, the API as it exists right now still has the other problems mentioned 
in the proposal and throughout this thread:
Implicit promotion of non-Optional types to Optional types makes it easy to 
accidentally call the wrong function.
Discoverability: Users looking to filter out ‘nil’ values have to know about 
something that does not say “filter”. Most new Swift users do not naturally 
discover this functionality.
Fragility: Adding “Collection” conformance to a type caused source 
incompatibility (as shown in the original proposal). In general, adding 
conformances should not break existing code.
Fragility: Changing a type from Optional to non-Optional (or vice versa) should 
not silently change behavior. But in this case, because of implicit optional 
promotion, it can.
Non-obvious behavior: In my experience, new Swift users do not intuitively 
understand what it means to “flatMap” a sequence of optionals, and could not 
intuitively understand the meaning of “flatten” in this context.
We can make Swift a more intuitive language by not pretending that Optionals 
are Sequences when they’re really not, and we can make it a more robust 
language by avoiding ambiguity between different versions of Sequence.flatMap 
in the presences of subtle type changes.

Anyway, I guess the review period ended last night, so we’ll know soon how this 
turns out.

-BJ


> On Nov 15, 2017, at 8:39 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 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 associate this operation with lists, which aren’t 
> common in Swift at all) or implementation details (neither Optional nor 
> Sequence actually has a flatten-method).
> Instead, I tend to look at the easiest way to explain how to get from input 
> to output, so here is what I have in my mind when I speak about 
> Sequence-Sequence flatmap:
> 
> 
> https://imgur.com/hy4rel1 
> 
> There is a transform, which turns an input value (red circle) into a 
> collection (blue basket) of output values (green squares).
> map takes an array of those input values, and stores each result-collection 
> in an array (light blue).
> flatten takes that container, unwraps each sub-collection, and stores its 
> contents together with the other elements.
> Note that empty collections aren’t skipped or removed — they just have 
> nothing that they could contribute to the final result, so no trace of them 
> is left.
> flatMap just is flatten performed on the output of map.
> 
> Now, Optionals… I could simply say „think of those as an array with a maximal 
> size of one“ — but because there’s really no fundamental difference, I just 
> copied the sequence-illustration, and changed one tiny bit: The 
> transformation doesn’t return multiple items now, so that the blue basket can 
> act as representation for an Optional.
> 
> 
> 
> https://imgur.com/qq95b31 
> 
> So conceptionally, both overrides are equivalent: The transformation always 
> produces something — an Optional, and that can contain a value, or it can be 
> empty, just like an array.
> You also see that the flatten step really does what it says: It removes one 
> layer of objects, and leaves a flush surface without gaps.
> 
> So, that should really be my last word in this discussion — I won’t add an 
> animation or start singing about Optionals ;-)
> 
> - Tino
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

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 associate this operation with lists, which aren’t 
common in Swift at all) or implementation details (neither Optional nor 
Sequence actually has a flatten-method).
Instead, I tend to look at the easiest way to explain how to get from input to 
output, so here is what I have in my mind when I speak about Sequence-Sequence 
flatmap:


https://imgur.com/hy4rel1

There is a transform, which turns an input value (red circle) into a collection 
(blue basket) of output values (green squares).
map takes an array of those input values, and stores each result-collection in 
an array (light blue).
flatten takes that container, unwraps each sub-collection, and stores its 
contents together with the other elements.
Note that empty collections aren’t skipped or removed — they just have nothing 
that they could contribute to the final result, so no trace of them is left.
flatMap just is flatten performed on the output of map.

Now, Optionals… I could simply say „think of those as an array with a maximal 
size of one“ — but because there’s really no fundamental difference, I just 
copied the sequence-illustration, and changed one tiny bit: The transformation 
doesn’t return multiple items now, so that the blue basket can act as 
representation for an Optional.



https://imgur.com/qq95b31

So conceptionally, both overrides are equivalent: The transformation always 
produces something — an Optional, and that can contain a value, or it can be 
empty, just like an array.
You also see that the flatten step really does what it says: It removes one 
layer of objects, and leaves a flush surface without gaps.

So, that should really be my last word in this discussion — I won’t add an 
animation or start singing about Optionals ;-)

- Tino

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Stefan Mayer-Popp via swift-evolution]

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 production and reuse their 
proven functionality without the requirement to transform the code to Swift.
The complexity of the Swift language itself isn't even touched in any area a 
“casual” developer uses, i personally see no argument of not integrating this 
feature for Swift.

I for myself can see a lot new possibilities and more reasons (and better 
arguments) for using Swift in other areas in my company like a normal phone app 
or some command-line tools. 
Symbiosis is great lets have some fun with Swython, Swuby or SwHP in future.

--
Stefan Mayer-Popp



> On 15. Nov 2017, at 11:08, Rick Mann via swift-evolution 
>  wrote:
> 
> +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, 2017, at 23:29 , Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hi All,
>> 
>> As a peer to the DynamicCallable proposal 
>> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d), I’d like 
>> to get your feedback on making member lookup dynamically extensible.  My 
>> primary motivation is to improve interoperability with dynamic languages 
>> like Python, Perl, Ruby, Javascript, etc, but there are other use cases 
>> (e.g. when working with untyped JSON).
>> 
>> In addition to being a high impact on expressivity of Swift, I believe an 
>> implementation can be done in a way with changes that are localized, and 
>> thus not have significant impact on the maintainability of the compiler as a 
>> whole.  Once the pitch phase of this proposal helps refine the details, I’ll 
>> be happy to prepare an implementation for consideration.
>> 
>> In case it is useful, I’m working on cleaning up my current prototype Python 
>> bindings.  I’ll share them in the next day or two in case they are useful to 
>> provide context.  It is amazingly simple: less than 500 lines of Swift code 
>> (plus some small additional C header glue to work around clang importer 
>> limitations) enables impressive interoperability.  The only problems are the 
>> verbosity addressed by this proposal and the peer DynamicCallable proposal.
>> 
>> 
>> Here is the canonical proposal URL:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
>> 
>> A snapshot of the proposal is included below in case it is useful.  Thanks 
>> in advance for help improving the proposal!
>> 
>> -Chris
>> 
>> 
>> Introduce User-defined "Dynamic Member Lookup" Types
>> 
>>  • Proposal: SE-
>>  • Author: Chris Lattner
>>  • Review Manager: TBD
>>  • Status: Awaiting implementation
>> Introduction
>> 
>> This proposal introduces a new DynamicMemberLookupProtocol type to the 
>> standard library. Types that conform to it provide "dot" syntax for 
>> arbitrary names which are resolved at runtime. It is simple syntactic sugar 
>> which allows the user to write:
>> 
>>a = someValue.someMember
>> 
>>someValue.
>> someMember = a
>> and have it be interpreted by the compiler as:
>> 
>>  a = someValue[dynamicMember: "someMember"
>> ]
>>  someValue[
>> dynamicMember: "someMember"] = a
>> Many other languages have analogous features (e.g. the composition of 
>> Objective-C's explicit properties and underlying messaging infrastructure). 
>> This sort of functionality is great for implementing dynamic language 
>> interoperability, dynamic proxy APIs, and other APIs (e.g. for JSON 
>> processing).
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation and Context
>> 
>> Swift is well known for being exceptional at interworking with existing C 
>> and Objective-C APIs, but its support for calling APIs written in scripting 
>> languages like Python, Perl, and Ruby is quite lacking.
>> 
>> C and Objective-C are integrated into Swift by expending a heroic amount of 
>> effort into integrating Clang ASTs, remapping existing APIs in an attempt to 
>> feel "Swifty", and by providing a large number of attributes and 
>> customization points for changing the behavior of this integration when 
>> writing an Objective-C header. The end result of this massive investment of 
>> effort is that Swift provides a better experience when programming against 
>> these legacy APIs than Objective-C itself did.
>> 
>> When considering the space of dynamic languages, three things are clear: 1) 
>> there are several different languages of interest, and they each have 
>> significant interest in different quarters: for example, Python is big in 
>> data science and machine learning, Ruby is p

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

[Rick Mann via swift-evolution]

+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, 2017, at 23:29 , Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi All,
> 
> As a peer to the DynamicCallable proposal 
> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d), I’d like 
> to get your feedback on making member lookup dynamically extensible.  My 
> primary motivation is to improve interoperability with dynamic languages like 
> Python, Perl, Ruby, Javascript, etc, but there are other use cases (e.g. when 
> working with untyped JSON).
> 
> In addition to being a high impact on expressivity of Swift, I believe an 
> implementation can be done in a way with changes that are localized, and thus 
> not have significant impact on the maintainability of the compiler as a 
> whole.  Once the pitch phase of this proposal helps refine the details, I’ll 
> be happy to prepare an implementation for consideration.
> 
> In case it is useful, I’m working on cleaning up my current prototype Python 
> bindings.  I’ll share them in the next day or two in case they are useful to 
> provide context.  It is amazingly simple: less than 500 lines of Swift code 
> (plus some small additional C header glue to work around clang importer 
> limitations) enables impressive interoperability.  The only problems are the 
> verbosity addressed by this proposal and the peer DynamicCallable proposal.
> 
> 
> Here is the canonical proposal URL:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> 
> A snapshot of the proposal is included below in case it is useful.  Thanks in 
> advance for help improving the proposal!
> 
> -Chris
> 
> 
> Introduce User-defined "Dynamic Member Lookup" Types
> 
>   • Proposal: SE-
>   • Author: Chris Lattner
>   • Review Manager: TBD
>   • Status: Awaiting implementation
> Introduction
> 
> This proposal introduces a new DynamicMemberLookupProtocol type to the 
> standard library. Types that conform to it provide "dot" syntax for arbitrary 
> names which are resolved at runtime. It is simple syntactic sugar which 
> allows the user to write:
> 
> a = someValue.someMember
> 
> someValue.
> someMember = a
> and have it be interpreted by the compiler as:
> 
>   a = someValue[dynamicMember: "someMember"
> ]
>   someValue[
> dynamicMember: "someMember"] = a
> Many other languages have analogous features (e.g. the composition of 
> Objective-C's explicit properties and underlying messaging infrastructure). 
> This sort of functionality is great for implementing dynamic language 
> interoperability, dynamic proxy APIs, and other APIs (e.g. for JSON 
> processing).
> 
> Swift-evolution thread: Discussion thread topic for that proposal
> 
> Motivation and Context
> 
> Swift is well known for being exceptional at interworking with existing C and 
> Objective-C APIs, but its support for calling APIs written in scripting 
> languages like Python, Perl, and Ruby is quite lacking.
> 
> C and Objective-C are integrated into Swift by expending a heroic amount of 
> effort into integrating Clang ASTs, remapping existing APIs in an attempt to 
> feel "Swifty", and by providing a large number of attributes and 
> customization points for changing the behavior of this integration when 
> writing an Objective-C header. The end result of this massive investment of 
> effort is that Swift provides a better experience when programming against 
> these legacy APIs than Objective-C itself did.
> 
> When considering the space of dynamic languages, three things are clear: 1) 
> there are several different languages of interest, and they each have 
> significant interest in different quarters: for example, Python is big in 
> data science and machine learning, Ruby is popular for building server side 
> apps, and even Perl is in still widely used. 2) These languages have decades 
> of library building behind them, sometimes with significant communities and 
> 3) there are one or two orders of magnitude more users of these libraries 
> than there are people currently using Swift.
> 
> While it is theoretically possible to expend the same level of effort on each 
> of these languages and communities as has been spent on Objective-C, it is 
> quite clear that this would both ineffective as well as bad for Swift: It 
> would be ineffective, because the Swift community has not leverage over these 
> communities to force auditing and annotation of their APIs. It would be bad 
> for Swift because it would require a ton of language-specific support (and a 
> number of third-party dependencies) onto the compiler and runtime, each of 
> which makes the implementation significantly more complex, difficult to 
> reason about, difficult to maintain, and difficult to test the supported

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

[Andrew Thompson via swift-evolution]

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 we have:

extension PyRef {
var one: Int {
return 1
}
}

foo.bar.one // returns 1, because it translates into foo[dynamic: “bar”].one

This to me is hinting that dynamic member lookup will only be applied to one 
property at a time. In order for it to work on multiple levels, the type being 
returned by the subscript operation must still conform to DynamicMemberLookup. 
Is this how you envisioned it to work?

Cheers,
Andrew

> Hi All,
> 
> As a peer to the DynamicCallable proposal 
> (https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 
> ), I’d like 
> to get your feedback on making member lookup dynamically extensible.  My 
> primary motivation is to improve interoperability with dynamic languages like 
> Python, Perl, Ruby, Javascript, etc, but there are other use cases (e.g. when 
> working with untyped JSON).
> 
> In addition to being a high impact on expressivity of Swift, I believe an 
> implementation can be done in a way with changes that are localized, and thus 
> not have significant impact on the maintainability of the compiler as a 
> whole.  Once the pitch phase of this proposal helps refine the details, I’ll 
> be happy to prepare an implementation for consideration.
> 
> In case it is useful, I’m working on cleaning up my current prototype Python 
> bindings.  I’ll share them in the next day or two in case they are useful to 
> provide context.  It is amazingly simple: less than 500 lines of Swift code 
> (plus some small additional C header glue to work around clang importer 
> limitations) enables impressive interoperability.  The only problems are the 
> verbosity addressed by this proposal and the peer DynamicCallable proposal.
> 
> 
> Here is the canonical proposal URL:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
> 
> 
> A snapshot of the proposal is included below in case it is useful.  Thanks in 
> advance for help improving the proposal!
> 
> -Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

~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 to local functions it still 
>> strikes me as a poor use of engineering resources to fix them (though I do 
>> agree they have problems). A better use of resources would be:
>> 
>>   1. Deprecate local functions.
>>   2. Allow closures when assigned to a function type to be:
>>   2a. Recursive.
>>   2b. Annotatable with:
>> 2bi.  @inline
>> 2bii. @escaping
>>   2c. Generic.
>> 
>> That would be a similar engineering effort and give a better short term 
>> result of better closures which would be much more widely applicable as well 
>> as addressing the issues with local functions.
> 
> I believe generic closures would require adding higher rank types to Swift.  
> That would be pretty cool but I suspect the engineering effort is at least an 
> order of magnitude greater than the changes discussed in this thread.

100% correct. Slava raises good points about implementation, I’ll raise one 
about semantics:

Without sufficient restrictions on this kind of polymorphism, type checking 
will become significantly more difficult for little corresponding benefit.  
Enabling the formation of polymorphic types just because you’re near an arrow 
means all sorts of fun things now get to happen

let f = { x in { y in y } }

This program is illegal without a type signature, but still typeable in that 
Swift will try to look for bindings to the tn’s in this signature

f :  (T0) -> (T1) -> T1

This is good - this is the most general unifier for this expression promised to 
us by the “Hindley-Milner-like” label we have in the type checker docs.

Given even rank-2 types, the most general unifier is (ideally) now 

f :  (T0) -> ( (T1) -> T1)

Which is significant because despite an obvious isomorphism, the former is not 
a specialization of the latter.  It is a completely separate polytype that 
would require additional structural rules to recover the correct behavior.  
This can also block inference or generate counterintuitive unifiers if we’re 
forced to e.g. unify nested polytypes against each other.

~Robert Widmann

> 
>> 
>> It also gives a better long term result of not having to maintain local 
>> functions.
>>   
>> 
>>   -- Howard.
>> 
>>> On 15 November 2017 at 09:08, Alex Lynch via swift-evolution 
>>>  wrote:
>>> The inference algebra just suggested was enjoyable to read, but is still a 
>>> new syntax. Which is interesting and deserving of its own proposal. The 
>>> purpose of this proposal is simply to introduce the existing capture syntax 
>>> to local functions. Thanks to everyone's feedback pointing out that the 
>>> `self` reference analysis is a deeper question than initially realized. 
>>> 
>>> Alex
>>> 
> On Tue, Nov 14, 2017 at 4:36 PM, Mike Kluev via swift-evolution 
>  wrote:
> On 14 November 2017 at 21:02, David Hart  wrote:
 
> 
> 
> I’d be very hesitant to introduce this syntax:
> 
> it’s new syntax, so it comes with a complexity tax (it isn’t naturally 
> obvious what it means for a func to be weak)
> it’s only sugar for the capture of self
 
 it might cover well over 90% of use cases (by my "pessimistic" 
 estimate)... if someone has a quick way to scan and analyse, say, github 
 swift sources we may even know that current percentage number of real life 
 usage.
> it doesn’t transpose well to local closures
 
 the last one - maybe not. follow me:
 
 let closure = { [weak self, bar] in ... }
 
 which today can be written as: 
 
 let closure = { [weak self, bar] () -> Int in ... } // full form
 
 or as:
 
 let closure: () -> Int = { [weak self, bar] in ... } // full form
 
 which allows this change:
 
 let closure:  [weak self, bar] () -> Int = { ... } // full alt form
 
 or in alternative form:
 
 let closure:  weak () -> Int = { [bar] in ... } // short hand form
 
 same can be with functions:
 
 func fn() -> Int { [weak self, bar] in ... } // full form
 
 weak func fn() -> Int { [bar] in ... } // short hand form
 
 the two capture attributes will in practice be "close" to each other:
 
 weak func fn() {
 [bar] in
 
 }
 
 and in majority of cases there will be only weak self:
 
 weak func fn() {
 
 }
 
 Mike
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolu