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

[Chris Lattner via swift-evolution]

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 

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

[Robert Widmann via swift-evolution]

A quick thing I noticed on a first read (sort of tangential to the rest of the 
discussion) is that it would be a good idea to land warnings for potential 
reference cycles sooner rather than later.

I have an (un-rebased) branch that lays out what parts of Sema needs to be 
touched to make this happen and have SR-1807 
(https://bugs.swift.org/browse/SR-1807) open for this in general if anybody 
would like to pick this up and carry it over the goal line.  Note that it’s not 
quite a starter bug.

Otherwise I’ll allocate time to it later on this winter.

~Robert Widmann 

2017/11/15 2:01、David Hart via swift-evolution のメール:

> 
> 
>> On 15 Nov 2017, at 03:56, 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.
> 
> Even if I agreed, which I don’t, I’m fairly sure it’s much too late in 
> Swift’s timeline to deprecate something as huge as 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.
>> 
>> 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-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
___
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

[David Hart via swift-evolution]

> On 15 Nov 2017, at 03:56, 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.

Even if I agreed, which I don’t, I’m fairly sure it’s much too late in Swift’s 
timeline to deprecate something as huge as 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.
> 
> 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-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] [Review] SE-0189: Restrict Cross-module Struct Initializers

[David Hart via swift-evolution]

> What is your evaluation of the proposal?
> 
It makes total sense. It’s a hole to plug in the resilience story.
> 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?
> 
It feels very Swift because it protects users from unknowingly placing 
themselves at risk of future source-breakage.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
Not aware of any.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
Several reads and made sure I understood everything.
> Thanks,
> Ted Kremenek
> 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] [Review] SE-0189: Restrict Cross-module Struct Initializers

[David Hart via swift-evolution]

> On 14 Nov 2017, at 22:24, Jordan Rose  wrote:
> 
> Hi, David. This only affects cross-module use cases, which means that the 
> automatically synthesized initializer doesn’t come into play (because it’s 
> not public). Is the clarification you’re looking for something like “a 
> 'source-breaking change’ is something that can cause previously compiling 
> code in another module to result in compile-time errors”?

Oh, I wasn’t aware that the automatically synthesised initialiser wasn’t 
public. I didn’t even test it :-/

> Thanks for pointing out the potential for confusion here!
> Jordan
> 
> 
>> On Nov 14, 2017, at 12:55, David Hart > > wrote:
>> 
>> I was initially quite confused about the proposal's first sentence: "Adding 
>> a property to a public struct in Swift ought to not be a source-breaking 
>> change.” Because I nearly always rely (like many developers) on struct 
>> automatic initializers, adding a property is pretty much always a 
>> source-breaking if I don’t write an explicit initializer with the same 
>> signature as the old automatic. Can something be done to clarify the 
>> proposal in that regard or is it too late?
>> 
>> David.
>> 
>>> On 14 Nov 2017, at 20:31, Ted Kremenek via swift-evolution 
>>> > wrote:
>>> 
>>> The review of "SE-0189: Restrict Cross-module Struct Initializers" begins 
>>> now and runs through November 21, 2017.
>>> 
>>> The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
>>>  
>>> 
>>> Reviews are an important part of the Swift evolution process. All review 
>>> feedback 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 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/0189-restrict-cross-module-struct-initializers.md
>>>  
>>> 
>>> ...
>>> Reply text
>>> ...
>>> Other replies
>>> What goes into a review of a proposal?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. 
>>> 
>>> When reviewing a proposal, here are some questions to consider:
>>> 
>>> 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?
>>> 
>>> Thanks,
>>> Ted Kremenek
>>> 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] [swift-dev] Re-pitch: Deriving collections of enum cases

[Xiaodi Wu via swift-evolution]

On Tue, Nov 14, 2017 at 11:06 PM, Brent Royal-Gordon  wrote:

> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
>
> 1. It must be possible to easily access the count of values, and to access
>> any particular value using contiguous `Int` indices. This could be achieved
>> either by directly accessing elements in the list of values through an Int
>> subscript, or by constructing an Array from the list of values.
>>
>> 2. It must be possible to control the order of values in the list of
>> values, either by using source order or through some other simple,
>> straightforward mechanism.
>>
>
> OK, first of all, nowhere in the proposal text are these requirements
> stated as part of the use case. You're free to put forward new use cases,
> but here I am trying to design the most elegant way to fulfill a stated
> need and you're telling me that it's something other than what's written.
>
>
> Honestly, re-reading the proposal, it never cites a fully-formed use case.
> Instead, it cites several blog posts, Stack Overflow questions, and small
> code samples without digging in to the underlying reasons why developers
> are doing what they're doing. Most of the people discussing it so far seem
> to have had a tacit understanding that we wanted roughly Array-like access,
> but we haven't explicitly dug into which properties of an Array are
> important.
>
> (If anyone involved feels like they had a different understanding of the
> use case, please speak up.)
>
> I think this is a place where the proposal can be improved, and I'm
> willing to do some writing to improve it.
>
> You say that:
>>
>>  Essentially all other uses for enumeration of enum cases can be
>> trivially recreated based on just that.
>>
>>
>> But with this use case in mind, we can see that it is "trivial" in the
>> sense that the annoying boilerplate you need to bridge the significant
>> impedance mismatch is easy to come up with. Yes, you could construct an
>> array using the magic `for` loop, but that would be a serious pain. (And
>> there would be no ergonomic, mistake-resistant way to hide that pain behind
>> a function/initializer call, because there's no way to say that a parameter
>> must be a metatype for an enum.) What you really want is a way to access or
>> construct an `Array` or array-like type containing the type's values.
>>
>
> You cannot truly believe that
>
> ```
> var cases = [BugStatus]()
> for c in BugStatus.self { cases.append(c) }
> ```
>
> is "serious pain." Yes, part of being an incomplete implementation is that
> it lacks the ergonomics of a fleshed-out conformance to `Collection`. But
> "serious pain"?
>
>
> Yes, I'll stand by "serious pain".
>

If only all of life's challenges were such "serious pain."


> This is fundamentally a convenience feature,
>

I greatly disagree with this characterization of the proposed feature. If
it were "fundamentally a convenience," then it would be best deferred from
Swift 5 entirely.

No, this feature is important to discuss--and hopefully implement--in the
Swift 5 timeframe because it is related to resilience. It is currently
_impossible_ to get all the cases of an enum. Even when you manually write
boilerplate, it can only cover the existing cases of an enum; if the enum
is vended by a library that later adds a case, your code may break. And if
you peer into the memory at runtime to do clever things, the runtime layout
of enums is not guaranteed at present. Put simply, you cannot retrieve all
the cases of an enum in today's Swift in a future-proof way. Making it
possible to do so is not about convenience--not at all. Convenience can
(and should, I'd argue) be deferred while more urgent solutions need to be
shipped first.

so it needs to actually *be* convenient—more convenient than writing out
> the enum cases in an array literal. Forcing users to write imperative-style
> code that can't be encapsulated is not convenient.
>
> The point here is that even a minimal step towards what we agree is the
> ideal design would make _possible_ what today is _impossible_: namely,
> future-proof enumeration of all the cases of an enum type without
> associated values.
>
>>
> We can take a minimal step towards having the feature…or we can just have
> the feature.
>

The minimal step I propose makes _possible_ the core use case in its
entirety. Again, what makes this proposal so timely is that it's about
making _possible_ certain uses of resilient enums that are currently
_impossible_. The "feature" here to be achieved is the _possibility_ of
enumerating all the cases of an enum.

*Actually* conforming the metatype to `Sequence` or `Collection` would be a
>> different story. There, you could construct `Array`s or access elements
>> using ordinary APIs and type system features. And you could write generic
>> algorithms which used the set of all types: they would require conformance
>> to `Sequence` or `Collection`, and users would specify `Foo.Type` as the
>> 

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

[Slava Pestov via swift-evolution]

> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution 
>  wrote:
> 
>   2. Allow closures when assigned to a function type to be:
>   2a. Recursive.

Local functions can also be mutually recursive:

func f() {
  func foo() { bar() }
  func bar() { foo() }
}

This would not work with let bindings, which are not visible before the 
location where they are defined.

>   2b. Annotatable with:
> 2bi.  @inline

Neither closures nor local functions benefit from being annotated with 
@_inlineable, because they can only be referenced from inside their defining 
function, and not across module boundaries. So the optimizer can already inline 
the function or closure if needed.

> 2bii. @escaping
>   2c. Generic.

See my other response to this thread.

Slava
___
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

[Mike Kluev via swift-evolution]

On 14 November 2017 at 21:36, Mike Kluev  wrote:

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

i did a quick & dirty search on github (queries below). here are some stats:

1) "weak var" - 946K hits

2) "weak self" - 168K hits

3) "weak" - 1127K hits

the summ of "weak var" + "weak self" = 1114K hits

number of "weak" - 1114K = 13K

let's assume this 13K is for weak "something" which is not "self"

number of "weak something" + "weak self" = 181K

"weak self" = 168K / 181K = 93%

"weak something" = 13K / 181K = 7%

the search queries for those interested:

https://github.com/search?utf8=✓=%22weak+var%22+filename%3A.swift=Code

https://github.com/search?utf8=✓=%22weak+self%22+filename%3A.swift=Code

https://github.com/search?utf8=✓=%22weak%22+filename%3A.swift=Code


note that you have to rerun the search multiple times until it settles
around some number.
also note, you can't easily use [ ] or other punctuation in github builtin
search.

the stat suggests that in 90%+ real-life cases [weak self] is used so the
"weak func" syntax sugar is worth to consider as an addition to this
proposal.

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

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

[Brent Royal-Gordon via swift-evolution]

> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
> 
> 1. It must be possible to easily access the count of values, and to access 
> any particular value using contiguous `Int` indices. This could be achieved 
> either by directly accessing elements in the list of values through an Int 
> subscript, or by constructing an Array from the list of values.
> 
> 2. It must be possible to control the order of values in the list of values, 
> either by using source order or through some other simple, straightforward 
> mechanism.
>  
> OK, first of all, nowhere in the proposal text are these requirements stated 
> as part of the use case. You're free to put forward new use cases, but here I 
> am trying to design the most elegant way to fulfill a stated need and you're 
> telling me that it's something other than what's written.

Honestly, re-reading the proposal, it never cites a fully-formed use case. 
Instead, it cites several blog posts, Stack Overflow questions, and small code 
samples without digging in to the underlying reasons why developers are doing 
what they're doing. Most of the people discussing it so far seem to have had a 
tacit understanding that we wanted roughly Array-like access, but we haven't 
explicitly dug into which properties of an Array are important.

(If anyone involved feels like they had a different understanding of the use 
case, please speak up.)

I think this is a place where the proposal can be improved, and I'm willing to 
do some writing to improve it.

> You say that:
> 
>>  Essentially all other uses for enumeration of enum cases can be trivially 
>> recreated based on just that.
> 
> 
> But with this use case in mind, we can see that it is "trivial" in the sense 
> that the annoying boilerplate you need to bridge the significant impedance 
> mismatch is easy to come up with. Yes, you could construct an array using the 
> magic `for` loop, but that would be a serious pain. (And there would be no 
> ergonomic, mistake-resistant way to hide that pain behind a 
> function/initializer call, because there's no way to say that a parameter 
> must be a metatype for an enum.) What you really want is a way to access or 
> construct an `Array` or array-like type containing the type's values.
> 
> You cannot truly believe that
> 
> ```
> var cases = [BugStatus]()
> for c in BugStatus.self { cases.append(c) }
> ```
> 
> is "serious pain." Yes, part of being an incomplete implementation is that it 
> lacks the ergonomics of a fleshed-out conformance to `Collection`. But 
> "serious pain"?

Yes, I'll stand by "serious pain". This is fundamentally a convenience feature, 
so it needs to actually *be* convenient—more convenient than writing out the 
enum cases in an array literal. Forcing users to write imperative-style code 
that can't be encapsulated is not convenient.

> The point here is that even a minimal step towards what we agree is the ideal 
> design would make _possible_ what today is _impossible_: namely, future-proof 
> enumeration of all the cases of an enum type without associated values.

We can take a minimal step towards having the feature…or we can just have the 
feature.

> *Actually* conforming the metatype to `Sequence` or `Collection` would be a 
> different story. There, you could construct `Array`s or access elements using 
> ordinary APIs and type system features. And you could write generic 
> algorithms which used the set of all types: they would require conformance to 
> `Sequence` or `Collection`, and users would specify `Foo.Type` as the generic 
> parameter.
> 
> Indeed. The point here is that we don't need a name for this protocol. You'd 
> be able to write useful generic algorithms by using functions such as `map` 
> on `T.self` with intuitive constraints such as `T where T.Type : Collection`. 
> Isn't that a sublime way of expressing exactly what we mean? 

It is! As I said, I love the idea of conforming the metatype to 
`Collection`—it's very elegant. But the only advantage I can identify over this 
proposal is a slight gain in elegance, while its *disadvantages*—requiring 
several nontrivial enhancements to the language, and therefore deferring large 
amounts of very desirable functionality to an unspecified future release—are 
significant.

Basically, I don't think it's worth waiting for the "sublime way".

(There's also the disadvantage that the meaning of `Foo.self[i]` is not 
immediately obvious in the way `Foo.allValues[i]` is. As it is, I'm not totally 
convinced that `ValueEnumerable` is an obvious enough name; `Foo.self` would be 
much more problematic in that sense.)

(And there's the opt-in question. Public types may not *want* to participate in 
this feature, but you seem to suggest they should have to.)

> But I suspect that would require deeper compiler changes than we can be 
> certain to get in Swift 5 or really at any specific point on the roadmap, and 
> I don't think we should delay this feature indefinitely to get a 

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

[Howard Lovatt via swift-evolution]

You can add generic closures with some name mangling and simple
transformations, nothing very hard.

The compiler can emit the following for example:

// User writes
let increment: (T) -> T = { $0 + 1 }
increment(1) // 2
increment(1.1) // 2.1


// Compiler issues
struct _Generic_Increment { // Mangle name
let increment: (T) -> T = { $0 + 1 }
}
_Generic_Increment().increment(1) // 2
_Generic_Increment().increment(1.1) // 2.1


It's plausible that the compiler can do better than the above, but the
above would be sufficient and is easy to do.

  -- Howard.

On 15 November 2017 at 14:02, Matthew Johnson 
wrote:

>
>
> Sent from my iPhone
>
> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> 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.
>
>
> 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 <
> swift-evolution@swift.org> 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 <
>> swift-evolution@swift.org> 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-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] Adding Result to the Standard Library

[Hooman Mehr via swift-evolution]

Oops, forgot to put the initializers that are the most useful:

public init(_ expression: @autoclosure () throws -> T) {
do { self = .value(try expression() ) }
catch { self = .error(error) }
}

public init(_ closure: () throws -> T) {
do { self = .value(try closure()) }
catch { self = .error(error) }
}


> On Nov 14, 2017, at 6:57 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
> You can support all styles with enum as well. What don’t you do this:
> 
> public enum Result {
> 
> case value(T)
> case error(Error)
> 
> public init(_ value: T) { self = .value(value) }
> public init(error: Error) { self = .error(error) }
> 
> public func get() throws -> T {
> switch self {
> case let .value(value): return value
> case let .error(error): throw error }
> }
> 
> public func map(_ transform: (T) throws -> U) throws -> U { return try 
> transform(get()) }
> 
> public var value: T? {
> switch self {
> case let .value(value): return value
> case .error: return nil }
> }
> 
> public var error: Error? {
> switch self {
> case .value: return nil
> case let .error(error): return error }
> }
> }
> 
> 
>> On Nov 14, 2017, at 3:40 PM, Guillaume Lessard via swift-evolution 
>> > wrote:
>> 
>> I’m late to this particular party, but having just caught up with the thread 
>> I’m surprised that no one substantially addressed the stylistic duality that 
>> a `public enum Result` would bring.
>> 
>> In short, I’d rather Result be a struct than an enum.
>> 
>> I too implemented a Result, for obvious reasons. I was, however, unsatisfied 
>> that it added another interface for error handling, namely switching over 
>> the enum — it’s not really better, not really worse, but now there are more 
>> error handling patterns to look for in your code.
>> 
>> My solution was to simply switch to a `struct Result`, where the enum is 
>> private. The only way to get the value out is via a throwing method. See 
>> > > for a 
>> no-frills implementation.
>> 
>> This has all the advantages of the Result enum — it’s easily used in 
>> asynchronous situations and can implement the desired functional/monadic 
>> niceties, but without exposing an unnecessary alternate interface to Swift’s 
>> native error handling.
>> 
>> Cheers,
>> Guillaume Lessard
>> 
>> ___
>> 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] [Review] SE-0189: Restrict Cross-module Struct Initializers

[Howard Lovatt via swift-evolution]

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/
proposals/0189-restrict-cross-module-struct-initializers.md



   -

   What is your evaluation of the proposal?

+1, more an oversight in the original design rather than a change. Funny
how this problem was caught for classes and not structs.

   -

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

Yes, focus is on getting rid of inconsistencies and problems.

   -

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

Yes, Swift is meant to be consistent.

   -

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

No

   -

   How much effort did you put into your review? A glance, a quick reading,
   or an in-depth study?

Glance

  -- Howard.

On 15 November 2017 at 08:24, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi, David. This only affects *cross-module* use cases, which means that
> the automatically synthesized initializer doesn’t come into play (because
> it’s not public). Is the clarification you’re looking for something like “a
> 'source-breaking change’ is something that can cause previously compiling
> code in another module to result in compile-time errors”?
>
> Thanks for pointing out the potential for confusion here!
> Jordan
>
>
> On Nov 14, 2017, at 12:55, David Hart  wrote:
>
> I was initially quite confused about the proposal's first sentence:
> "Adding a property to a public struct in Swift ought to not be a
> source-breaking change.” Because I nearly always rely (like many
> developers) on struct automatic initializers, adding a property is pretty
> much always a source-breaking if I don’t write an explicit initializer with
> the same signature as the old automatic. Can something be done to clarify
> the proposal in that regard or is it too late?
>
> David.
>
> On 14 Nov 2017, at 20:31, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The review of "SE-0189: Restrict Cross-module Struct Initializers" begins
> now and runs through *November 21, 2017*.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0189-restrict-cross-module-struct-initializers.md
>
> Reviews are an important part of the Swift evolution process. All review
> feedback 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 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/0189-restrict-cross-module-struct-initializers.md
> ...
> Reply text
> ...
> Other replies
>
> What goes into a review of a proposal?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift.
>
> When reviewing a proposal, here are some questions to consider:
>
>-
>
>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?
>
> Thanks,
> Ted Kremenek
> 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/swift-evolution

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

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

> 
> 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-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] Adding Result to the Standard Library

[Hooman Mehr via swift-evolution]

You can support all styles with enum as well. What don’t you do this:

public enum Result {

case value(T)
case error(Error)

public init(_ value: T) { self = .value(value) }
public init(error: Error) { self = .error(error) }

public func get() throws -> T {
switch self {
case let .value(value): return value
case let .error(error): throw error }
}

public func map(_ transform: (T) throws -> U) throws -> U { return try 
transform(get()) }

public var value: T? {
switch self {
case let .value(value): return value
case .error: return nil }
}

public var error: Error? {
switch self {
case .value: return nil
case let .error(error): return error }
}
}


> On Nov 14, 2017, at 3:40 PM, Guillaume Lessard via swift-evolution 
>  wrote:
> 
> I’m late to this particular party, but having just caught up with the thread 
> I’m surprised that no one substantially addressed the stylistic duality that 
> a `public enum Result` would bring.
> 
> In short, I’d rather Result be a struct than an enum.
> 
> I too implemented a Result, for obvious reasons. I was, however, unsatisfied 
> that it added another interface for error handling, namely switching over the 
> enum — it’s not really better, not really worse, but now there are more error 
> handling patterns to look for in your code.
> 
> My solution was to simply switch to a `struct Result`, where the enum is 
> private. The only way to get the value out is via a throwing method. See 
>  for a 
> no-frills implementation.
> 
> This has all the advantages of the Result enum — it’s easily used in 
> asynchronous situations and can implement the desired functional/monadic 
> niceties, but without exposing an unnecessary alternate interface to Swift’s 
> native error handling.
> 
> Cheers,
> Guillaume Lessard
> 
> ___
> 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] Improving capturing semantics of local functions

[Howard Lovatt via swift-evolution]

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.

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

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

[Xiaodi Wu via swift-evolution]

On Tue, Nov 14, 2017 at 5:49 AM, Brent Royal-Gordon 
wrote:

> On Nov 13, 2017, at 9:21 PM, Xiaodi Wu  wrote:
>
> ...I should add, if full conformance to `Collection` is still too much to
> ask, enabling "for `case` in Foo.self" by magic would itself address the
> entirety of the proposal's use case, adding no API surface area.
>
>
> No, Xiaodi. No, it would not.
>
> Okay, thus far we've talked vaguely about "accessing the cases of an
> enum", but let's talk a little more concretely about what that means. I
> think that, especially on Apple platforms, this is the most important
> concrete use case:
>
> PROBLEM:
>
> You have an enum like:
>
> enum BugStatus {
> case open, inProgress, resolved, closed, reopened
> var localizedName: String { … }
> }
>
> You wish to present these options in a user interface so a user can select
> one of them. For instance, if you're on iOS and using UITableView, you
> might want to present the enum's values through `UITableViewDataSource` and
> allow selection through `UITableViewDelegate`.
>
> REQUIREMENTS:
>
> 1. It must be possible to easily access the count of values, and to access
> any particular value using contiguous `Int` indices. This could be achieved
> either by directly accessing elements in the list of values through an Int
> subscript, or by constructing an Array from the list of values.
>
> 2. It must be possible to control the order of values in the list of
> values, either by using source order or through some other simple,
> straightforward mechanism.
>

OK, first of all, nowhere in the proposal text are these requirements
stated as part of the use case. You're free to put forward new use cases,
but here I am trying to design the most elegant way to fulfill a stated
need and you're telling me that it's something other than what's written.
But sure, let's proceed on this basis.

PROPOSED SOLUTION:
>
> You conform `BugStatus` to `ValueEnumerable`:
>
> enum BugStatus: ValueEnumerable {
> case open, inProgress, resolved, closed, reopened
> var localizedName: String { … }
> }
>
> And then write the table view data source to present the elements of
> `BugStatus.allValues`:
>
> class BugStatusDataSource: NSObject, UITableViewDataSource,
> UITableViewDelegate {
> @IBOutlet var tableView: UITableView?
> @objc dynamic var selected: BugStatus? { // Observable via KVO
> didSet { tableView.reloadData() }
> }
> func status(at indexPath: IndexPath) -> Status {
> BugStatus.allValues[indexPath.row]
> }
> func tableView(_: UITableView, numberOfRowsInSection section: Int) -> Int {
> return BugStatus.allValues.count
> }
> func tableView(_: UITableView, cellForRowAt indexPath: IndexPath) ->
> UITableViewCell {
> let status = self.status(at: indexPath)
> let identifier = (status == selected) ? "SelectedCell" : "RegularCell"
> let cell = tableView.dequeueReusableCell(withIdentifier: identifier, for:
> indexPath)
> cell.titleLabel.text = status.localizedName
> return cell
> }
> func tableView(_: UITableView, didSelectRowAt indexPath: IndexPath) {
> selected = status(at: indexPath)
> }
> }
>
> This is the most direct solution; a more sophisticated version might
> inject the list as an Array so that you can show a subset of the full set
> of values.
>
> EXTENSIONS:
>
> Now, let's quickly talk about a couple extensions of this use case:
>
> * The values, and the table view cells, are grouped into sections. This
> suggests some sort of two-level, nested structure, which may not use `Int`
> indices.
>
> * You want to write a *generic* data source which can present all the
> values of *any* ValueEnumerable type (or at least any conforming to a
> protocol that allows us to fill in their cells). For that purpose, it's
> helpful to have the type conform to *some* sort of protocol and expose the
> value list through that protocol.
>
> You say that:
>
>  Essentially all other uses for enumeration of enum cases can be
> trivially recreated based on just that.
>
>
> But with this use case in mind, we can see that it is "trivial" in the
> sense that the annoying boilerplate you need to bridge the significant
> impedance mismatch is easy to come up with. Yes, you could construct an
> array using the magic `for` loop, but that would be a serious pain. (And
> there would be no ergonomic, mistake-resistant way to hide that pain behind
> a function/initializer call, because there's no way to say that a parameter
> must be a metatype for an enum.) What you really want is a way to access or
> construct an `Array` or array-like type containing the type's values.
>

You cannot truly believe that

```
var cases = [BugStatus]()
for c in BugStatus.self { cases.append(c) }
```

is "serious pain." Yes, part of being an incomplete implementation is that
it lacks the ergonomics of a fleshed-out conformance to `Collection`. But
"serious pain"?

The point here is that even a minimal step towards what we agree is the
ideal design would make _possible_ what today is 

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

[David Waite via swift-evolution]

For some generic function

func doSomething() -> Result

You could write (potentially pseudocode);

func doSomething() throws -> String {
   return try doSomething().value()
}

with Result defined as:

enum Result { 
 case success(T)
 case error(Error) 
 func value() throws -> T {
 switch self {
case success(let t):
return t
case error(let e):
throw e
  }
  }
}

IMHO, the real value for a Result type (or Future/Promise type) in the core 
library would be the compiler support for the type. Why would you want to 
define two versions of the doSomething function just to deal with code that 
wants a Result and code which doesn't?

That, and people implementing Result themselves internally in 15 lines making 
it a question of supporting *everyone’s* Result types, not just a system type.

-DW
 
> On Nov 14, 2017, at 4:40 PM, Guillaume Lessard via swift-evolution 
>  wrote:
> 
> I’m late to this particular party, but having just caught up with the thread 
> I’m surprised that no one substantially addressed the stylistic duality that 
> a `public enum Result` would bring.
> 
> In short, I’d rather Result be a struct than an enum.
> 
> I too implemented a Result, for obvious reasons. I was, however, unsatisfied 
> that it added another interface for error handling, namely switching over the 
> enum — it’s not really better, not really worse, but now there are more error 
> handling patterns to look for in your code.
> 
> My solution was to simply switch to a `struct Result`, where the enum is 
> private. The only way to get the value out is via a throwing method. See 
>  for a 
> no-frills implementation.
> 
> This has all the advantages of the Result enum — it’s easily used in 
> asynchronous situations and can implement the desired functional/monadic 
> niceties, but without exposing an unnecessary alternate interface to Swift’s 
> native error handling.
> 
> Cheers,
> Guillaume Lessard
> 
> ___
> 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] Adding Result to the Standard Library

[Guillaume Lessard via swift-evolution]

I’m late to this particular party, but having just caught up with the thread 
I’m surprised that no one substantially addressed the stylistic duality that a 
`public enum Result` would bring.

In short, I’d rather Result be a struct than an enum.

I too implemented a Result, for obvious reasons. I was, however, unsatisfied 
that it added another interface for error handling, namely switching over the 
enum — it’s not really better, not really worse, but now there are more error 
handling patterns to look for in your code.

My solution was to simply switch to a `struct Result`, where the enum is 
private. The only way to get the value out is via a throwing method. See 
 for a 
no-frills implementation.

This has all the advantages of the Result enum — it’s easily used in 
asynchronous situations and can implement the desired functional/monadic 
niceties, but without exposing an unnecessary alternate interface to Swift’s 
native error handling.

Cheers,
Guillaume Lessard

___
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

[Alex Lynch via swift-evolution]

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 <
swift-evolution@swift.org> 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-evolution

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

[Mike Kluev via swift-evolution]

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

Re: [swift-evolution] [Review] SE-0189: Restrict Cross-module Struct Initializers

[Jordan Rose via swift-evolution]

Hi, David. This only affects cross-module use cases, which means that the 
automatically synthesized initializer doesn’t come into play (because it’s not 
public). Is the clarification you’re looking for something like “a 
'source-breaking change’ is something that can cause previously compiling code 
in another module to result in compile-time errors”?

Thanks for pointing out the potential for confusion here!
Jordan


> On Nov 14, 2017, at 12:55, David Hart  wrote:
> 
> I was initially quite confused about the proposal's first sentence: "Adding a 
> property to a public struct in Swift ought to not be a source-breaking 
> change.” Because I nearly always rely (like many developers) on struct 
> automatic initializers, adding a property is pretty much always a 
> source-breaking if I don’t write an explicit initializer with the same 
> signature as the old automatic. Can something be done to clarify the proposal 
> in that regard or is it too late?
> 
> David.
> 
>> On 14 Nov 2017, at 20:31, Ted Kremenek via swift-evolution 
>> > wrote:
>> 
>> The review of "SE-0189: Restrict Cross-module Struct Initializers" begins 
>> now and runs through November 21, 2017.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All review 
>> feedback 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 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/0189-restrict-cross-module-struct-initializers.md
>>  
>> 
>> ...
>> Reply text
>> ...
>> Other replies
>> What goes into a review of a proposal?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. 
>> 
>> When reviewing a proposal, here are some questions to consider:
>> 
>> 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?
>> 
>> Thanks,
>> Ted Kremenek
>> 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] Improving capturing semantics of local functions

[David Hart via swift-evolution]

> On 14 Nov 2017, at 20:41, Wallacy  wrote:
> 
> 
> 
> Em ter, 14 de nov de 2017 às 17:02, Mike Kluev via swift-evolution 
> > escreveu:
> On Mon, 13 Nov 2017 22:30:25 +0100 David Hart  > wrote:
> > On 13 Nov 2017, at 05:52, Slava Pestov  > > wrote:
> >
> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution 
> >> > wrote:
> >>
> >> By analogy with the current closure syntax, the capture list ought to go 
> >> somewhere before the parameter list, in one of these slots:
> >>
> >> 1.   func fn[foo, bar](param: T) throws -> T where T: Equatable { … }
> >> 2.   func fn[foo, bar](param: T) throws -> T where T: Equatable { … }
> >> 3.   func [foo, bar] fn(param: T) throws -> T where T: Equatable { … }
> >> 4.   [foo, bar] func fn(param: T) throws -> T where T: Equatable { … }
> >>
> >> Of these options, I actually think #4 reads best; 1 and 2 are very 
> >> cluttered, and 3 just seems weird. But it seems like the one that would be 
> >> easiest to misparse.
> >
> > Another option that reads nicely IMHO is
> >
> > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … }
> >
> > I think #4 is ambiguous with array literals unfortunately.
> 
> adding to the list of options:
> 
> 6. func fn(param: T) throws -> T where T: Equatable [foo, bar] { … }
> 
> otherwise +1 to #1 and to the one in proposal. also see about #4 below.
> 
> plus, if 90%+ of use cases in practice would be [weak self] -- (the only 
> examples shown in the proposals FTM) -- i would strongly consider this syntax 
> sugar in addition to a generic notation:
> 
> weak func fn(param: T) throws -> T where T: Equatable { … }
> 
> works with "unowned" as a bonus.
> 
> 
> weak func  to imply [weak self] is a good idea. 

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 doesn’t transpose well to local closures

On the other hand, the proposal attempts to resolve the problems mentioned in 
the Motivation section by introducing as little syntax as possible. And the 
little it does (capture lists) is no similar to closures that increased 
complexity tax is fairly low.

> weak func foo() {
>   self?.bar();
> }
> 
> unowned func foo() {
>   self.bar();
> }
> 
> Maybe this to:
> 
> onChange = weak { self?.bar() }
> 
> But we still have the problem using capture list.
> 
> And to avoid inconsistencies, I would leave the same way as the proposal.
> 
>  func local() { [weak self] in
> self?.bar()
> }
> 
> There's no perfect solution. And in this works fine today.
> 
>  
> if implement this sugar than some variation of #4 looks appealing to have 
> these capture things close.
> 
> 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-evolution

Re: [swift-evolution] [Review] SE-0189: Restrict Cross-module Struct Initializers

[David Hart via swift-evolution]

I was initially quite confused about the proposal's first sentence: "Adding a 
property to a public struct in Swift ought to not be a source-breaking change.” 
Because I nearly always rely (like many developers) on struct automatic 
initializers, adding a property is pretty much always a source-breaking if I 
don’t write an explicit initializer with the same signature as the old 
automatic. Can something be done to clarify the proposal in that regard or is 
it too late?

David.

> On 14 Nov 2017, at 20:31, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now 
> and runs through November 21, 2017.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
>  
> 
> Reviews are an important part of the Swift evolution process. All review 
> feedback 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 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/0189-restrict-cross-module-struct-initializers.md
>  
> 
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> 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?
> 
> Thanks,
> Ted Kremenek
> 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] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

[Jordan Rose via swift-evolution]

Hi, everyone, proposal author here. Caveat: I'll be on vacation for the last 
few days of this review period, so I won't see your comments after Saturday the 
18th (and possibly not even then, if you send them too late in the day). This 
is fine, of course, but if you have questions for me I may not be able to 
answer them until the following Monday, after the review has formally ended. 
Apologies if this ends up affecting you.

Thank you for your consideration and feedback!
Jordan

P.S. The implementation PR includes some changes to the Apple SDK overlays that 
demonstrate what's being proposed for imported C structs. I encourage you to 
take a look.


> On Nov 14, 2017, at 11:31, Ted Kremenek  wrote:
> 
> The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now 
> and runs through November 21, 2017.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
>  
> 
> Reviews are an important part of the Swift evolution process. All review 
> feedback 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 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/0189-restrict-cross-module-struct-initializers.md
>  
> 
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> 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?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

___
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

[Wallacy via swift-evolution]

Em ter, 14 de nov de 2017 às 17:02, Mike Kluev via swift-evolution <
swift-evolution@swift.org> escreveu:

> On Mon, 13 Nov 2017 22:30:25 +0100 David Hart  wrote:
>
>> > On 13 Nov 2017, at 05:52, Slava Pestov  wrote:
>> >
>> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >> By analogy with the current closure syntax, the capture list ought to
>> go somewhere before the parameter list, in one of these slots:
>> >>
>> >> 1.   func fn[foo, bar](param: T) throws -> T where T: Equatable { …
>> }
>> >> 2.   func fn[foo, bar](param: T) throws -> T where T: Equatable { …
>> }
>> >> 3.   func [foo, bar] fn(param: T) throws -> T where T: Equatable {
>> … }
>> >> 4.   [foo, bar] func fn(param: T) throws -> T where T: Equatable {
>> … }
>> >>
>> >> Of these options, I actually think #4 reads best; 1 and 2 are very
>> cluttered, and 3 just seems weird. But it seems like the one that would be
>> easiest to misparse.
>> >
>> > Another option that reads nicely IMHO is
>> >
>> > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … }
>> >
>> > I think #4 is ambiguous with array literals unfortunately.
>>
>
> adding to the list of options:
>
> 6. func fn(param: T) throws -> T where T: Equatable [foo, bar] { … }
>
> otherwise +1 to #1 and to the one in proposal. also see about #4 below.
>
> plus, if 90%+ of use cases in practice would be [weak self] -- (the only
> examples shown in the proposals FTM) -- i would strongly consider this
> syntax sugar in addition to a generic notation:
>
> weak func fn(param: T) throws -> T where T: Equatable { … }
>
> works with "unowned" as a bonus.
>
>
weak func  to imply [weak self] is a good idea.

weak func foo() {
  self?.bar();
}

unowned func foo() {
  self.bar();
}

Maybe this to:

onChange = weak { self?.bar() }

But we still have the problem using capture list.

And to avoid inconsistencies, I would leave the same way as the proposal.

 func local() { [weak self] in
self?.bar()
}


There's no perfect solution. And in this works fine today.



> if implement this sugar than some variation of #4 looks appealing to have
> these capture things close.
>
> 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-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

[Hooman Mehr via swift-evolution]

+1 It should have been like this from the get go.

> On Nov 14, 2017, at 11:31 AM, Ted Kremenek  wrote:
> 
> The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now 
> and runs through November 21, 2017.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
>  
> 
> Reviews are an important part of the Swift evolution process. All review 
> feedback 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 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/0189-restrict-cross-module-struct-initializers.md
>  
> 
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> 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?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

[swift-evolution] [Review] SE-0189: Restrict Cross-module Struct Initializers

[Ted Kremenek via swift-evolution]

The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now 
and runs through November 21, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
Reviews are an important part of the Swift evolution process. All review 
feedback 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 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/0189-restrict-cross-module-struct-initializers.md
...
Reply text
...
Other replies
What goes into a review of a proposal?

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

When reviewing a proposal, here are some questions to consider:

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?

Thanks,
Ted Kremenek
Review Manager
___
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

[Mike Kluev via swift-evolution]

On 14 November 2017 at 19:02, Mike Kluev  wrote:

> On Mon, 13 Nov 2017 22:30:25 +0100 David Hart  wrote:
>
> > On 13 Nov 2017, at 05:52, Slava Pestov  wrote:
>> >
>> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >> By analogy with the current closure syntax, the capture list ought to
>> go somewhere before the parameter list, in one of these slots:
>> >>
>> >> 1.   func fn[foo, bar](param: T) throws -> T where T: Equatable { …
>> }
>> >> 2.   func fn[foo, bar](param: T) throws -> T where T: Equatable { …
>> }
>> >> 3.   func [foo, bar] fn(param: T) throws -> T where T: Equatable {
>> … }
>> >> 4.   [foo, bar] func fn(param: T) throws -> T where T: Equatable {
>> … }
>> >>
>> >> Of these options, I actually think #4 reads best; 1 and 2 are very
>> cluttered, and 3 just seems weird. But it seems like the one that would be
>> easiest to misparse.
>> >
>> > Another option that reads nicely IMHO is
>> >
>> > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … }
>> >
>> > I think #4 is ambiguous with array literals unfortunately.
>>
>
> adding to the list of options:
>
> 6. func fn(param: T) throws -> T where T: Equatable [foo, bar] { … }
>
> otherwise +1 to #1 and to the one in proposal. also see about #4 below.
>
> plus, if 90%+ of use cases in practice would be [weak self] -- (the only
> examples shown in the proposals FTM) -- i would strongly consider this
> syntax sugar in addition to a generic notation:
>
> weak func fn(param: T) throws -> T where T: Equatable { … }
>
> works with "unowned" as a bonus.
>
> if implement this sugar than some variation of #4 looks appealing to have
> these capture things close.
>
>

the closer we have it to this English sentence the better IMHO:

weak throwing function "fn", capturing "foo" and "bar" weakly, using
generic type "T" which is "Equatable", having parameter "param" of type
"T", returning type "T", with the following body { ... }

Mike
___
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

[Mike Kluev via swift-evolution]

On Mon, 13 Nov 2017 22:30:25 +0100 David Hart  wrote:

> On 13 Nov 2017, at 05:52, Slava Pestov  wrote:
> >
> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> By analogy with the current closure syntax, the capture list ought to
> go somewhere before the parameter list, in one of these slots:
> >>
> >> 1.   func fn[foo, bar](param: T) throws -> T where T: Equatable { … }
> >> 2.   func fn[foo, bar](param: T) throws -> T where T: Equatable { … }
> >> 3.   func [foo, bar] fn(param: T) throws -> T where T: Equatable { …
> }
> >> 4.   [foo, bar] func fn(param: T) throws -> T where T: Equatable { …
> }
> >>
> >> Of these options, I actually think #4 reads best; 1 and 2 are very
> cluttered, and 3 just seems weird. But it seems like the one that would be
> easiest to misparse.
> >
> > Another option that reads nicely IMHO is
> >
> > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … }
> >
> > I think #4 is ambiguous with array literals unfortunately.
>

adding to the list of options:

6. func fn(param: T) throws -> T where T: Equatable [foo, bar] { … }

otherwise +1 to #1 and to the one in proposal. also see about #4 below.

plus, if 90%+ of use cases in practice would be [weak self] -- (the only
examples shown in the proposals FTM) -- i would strongly consider this
syntax sugar in addition to a generic notation:

weak func fn(param: T) throws -> T where T: Equatable { … }

works with "unowned" as a bonus.

if implement this sugar than some variation of #4 looks appealing to have
these capture things close.

Mike
___
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]

“Flatten”, in the context here (flattening a Sequence of Optionals), only makes 
sense if you consider Optional as a sequence of zero or one elements. While 
such a sequence does act very similarly to an Optional, the fact remains that 
Optional is not a Sequence, and is generally not treated as one by any other 
part of the language. It fundamentally makes no more sense to “flatten" a 
Sequence of Optionals than it does to “flatten" an Optional of a Sequence.

In my mind, filter makes sense because I’m filtering out some of the results of 
the transformation operation before they get put into the resulting array. It’s 
a different kind of operation; not a map, but a filterMap. (Maybe filteringMap 
would be clearer?) The operation is not “map into a new array, then filter”. 
It’s “run this transformation for each item. If it produces something, keep 
it.” There’s no filter or compact that runs on the entire collection.

-BJ





> On Nov 14, 2017, at 7:50 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> Yeah but it seems clear from the return type so I am not sure that much 
>> confusion would really exist.
> 
> 
> Afaics, there already is lots of confusion — that’s the reason for me to 
> write a sequence of posts in this topic, instead of an Optional ;-)
> The word „flatten“ is a quite honest description, so I wonder why words like 
> filter, remove, ignoring or skipping should be used instead.
> 
> „Compact“ would be less irritating, but I could imagine that it indicates 
> something like eliminating repeated occurrences.
> 
> Tino
> 
> (I’m quite close to attach a hand-drawn illustration of the flatMap process — 
> I don’t think you want that to happen ;-)
> 
> ___
> 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(_:)

[Tino Heth via swift-evolution]

> Yeah but it seems clear from the return type so I am not sure that much 
> confusion would really exist.


Afaics, there already is lots of confusion — that’s the reason for me to write 
a sequence of posts in this topic, instead of an Optional ;-)
The word „flatten“ is a quite honest description, so I wonder why words like 
filter, remove, ignoring or skipping should be used instead.

„Compact“ would be less irritating, but I could imagine that it indicates 
something like eliminating repeated occurrences.

Tino

(I’m quite close to attach a hand-drawn illustration of the flatMap process — I 
don’t think you want that to happen ;-)

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