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

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

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

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

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

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

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

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

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

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

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

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 {

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

> 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

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

> 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

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

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

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

> 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()

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

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 >

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

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

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

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 { //

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

> 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

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

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

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

> 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

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

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] [Review] SE-0189: Restrict Cross-module Struct Initializers

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

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

+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: > >

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

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,

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

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

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

“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

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

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