Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On 18 Feb 2017, at 04:26, John McCall via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0155: Normalize Enum Case Representation" begins now and > runs through next Friday, February 26th. The proposal is available here: > >

Re: [swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

On Sat, Feb 18, 2017 at 1:07 AM, David Waite wrote: > > > On Feb 17, 2017, at 10:53 PM, Xiaodi Wu wrote: > > > > This draft proposes something that's been discussed on this list several > times over the past few years, but now with a different

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

> > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md > > > > What

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 5:26 PM, Ben Cohen via swift-evolution > > wrote: > > Hi swift-evolution, > > Following up on Ted’s post regarding the opening up of stage 2, I’m starting > a thread to discuss improvements to the Dictionary

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

>> What is your evaluation of the proposal? For the same reasons as Xiaodi, this proposal could be potentially misleading if it introduces custom compiler magic, warning or errors that was not replicated for future property behaviours. But at the same time, it's very easy for even a seasoned

Re: [swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

> On Feb 17, 2017, at 10:53 PM, Xiaodi Wu wrote: > > This draft proposes something that's been discussed on this list several > times over the past few years, but now with a different spelling. However, > previous objections never centered around the spelling. > > As

Re: [swift-evolution] Dictionary Enhancements

Hi Jon, Thank you for the feedback, this is really valuable! A couple questions below. > On Feb 17, 2017, at 8:50 PM, Jonathan Hull via swift-evolution > wrote: > > Thoughts inline. > >> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution >>

Re: [swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

This draft proposes something that's been discussed on this list several times over the past few years, but now with a different spelling. However, previous objections never centered around the spelling. As discussed in previous threads on this topic, any such required keyword breaks retroactive

Re: [swift-evolution] [swift-evolution-announce] [Re-Review] SE-0104: Protocol-oriented integers

Sent from my iPhone > On Feb 17, 2017, at 17:45, Joe Groff wrote: > >• What is your evaluation of the proposal? Overall, a big +1 I'll 2nd not deprecating the BitwiseOperations protocol, though. >• Is the problem being addressed significant enough to warrant a

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> • What is your evaluation of the proposal? Very good. It's a much needed improvement to the language's integer protocols and type hierarchy. I would argue against the deprecation of the BitwiseOperations protocol though. I believe a bitset type would be a good candidate for conformance to

Re: [swift-evolution] final + lazy + fileprivate modifiers

My ideal scenario: 1) Go back to Swift 2 meaning of private 2) Add the ‘hidden’ axis I talked about in another thread. This will provide the capabilities of protected + friend (and allow extensions organized across files) using a consistent file-based approach that is easy to reason about.

[swift-evolution] [Proposal Draft] nil Values for Objective-C Primitives

Hello all! Following our previous discussion about importing primitives from Objective-C as optionals, I’ve written a draft proposal for your consideration. All feedback is greatly appreciated!

[swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

I wrote up the following draft proposal around attempting to clarify protocol implementation and protocol extensions, via annotating methods and properties meant to satisfy protocol requirements with additional keywords: "Types implementing protocols with optional features (either through

[swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

Hello Swift community, The review of "SE-0155: Normalize Enum Case Representation" begins now and runs through next Friday, February 26th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md

Re: [swift-evolution] Dictionary Enhancements

Sent from my iPad > On Feb 17, 2017, at 8:50 PM, Jonathan Hull via swift-evolution > wrote: > > Thoughts inline. > >> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution >> wrote: >> >> Hi swift-evolution, >> >> Following up

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 6:10 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez > wrote: > >> >> From Ted. >>> Relative to Swift 3, the bar for such changes is

Re: [swift-evolution] Dictionary Enhancements

Thoughts inline. > On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution > wrote: > > Hi swift-evolution, > > Following up on Ted’s post regarding the opening up of stage 2, I’m starting > a thread to discuss improvements to the Dictionary type. > > Here is a

Re: [swift-evolution] final + lazy + fileprivate modifiers

Sent from my iPad > On Feb 17, 2017, at 4:51 PM, Xiaodi Wu wrote: > > Although there was willingness to depart from conventions in other C-style > languages, I believe it was decided that having a counterpart to other > languages' "private" that isn't named private

Re: [swift-evolution] final + lazy + fileprivate modifiers

Sent from my iPad > On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez wrote: > > From Ted. >> Relative to Swift 3, the bar for such changes is significantly higher: >> >> The existing syntax/API being changed must be actively harmful. >> The new syntax/API must clearly be

Re: [swift-evolution] final + lazy + fileprivate modifiers

Sent from my iPad > On Feb 17, 2017, at 6:44 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution >> wrote: >>> On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> • What is your evaluation of the proposal? > Excellent, even better than the first take. Still not sure about the `FullWidth` design, but it'll do. • Is the problem being addressed significant enough to warrant a change to > Swift? > Yes, the previous protocols were confusing and ultimately

[swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Hello Swift community, The re-review of SE-0104 "Protocol-oriented integers" begins now and runs through February 25, 2017. This proposal was accepted for Swift 3, but was not implemented in time for the release. The revised proposal is available here:

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

> > >- What is your evaluation of the proposal? > > This document seems to propose two contradictory alternative solutions; I assume the goal is that the core team will choose one of two. I'm not sure that either is an improvement over the status quo, for reasons I outline below. > >- Is

Re: [swift-evolution] final + lazy + fileprivate modifiers

From Ted. > Relative to Swift 3, the bar for such changes is significantly higher: > > The existing syntax/API being changed must be actively harmful. > The new syntax/API must clearly be better and not conflict with existing > Swift syntax. > There must be a reasonably automatable migration

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Fri, Feb 17, 2017 at 5:49 PM, Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> Here, a function call is an _intentional_ act. Writing a function not >> meant to be

Re: [swift-evolution] [Review] SE-0154: Provide Custom Collections for Dictionary Keys and Values

What is your evaluation of the proposal? This is welcome improvement. Is the problem being addressed significant enough to warrant a change to Swift? Definitely. Does this proposal fit well with the feel and direction of Swift? It does indeed. If you have used other languages or libraries

[swift-evolution] [Review] SE-0154: Provide Custom Collections for Dictionary Keys and Values

Hello Swift community, The review of SE-0154 "Provide Custom Collections for Dictionary Keys and Values" begins now and runs through February 22, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > Here, a function call is an _intentional_ act. Writing a function not > meant to be called is an _intentional_ act. It is strange that you would > demand the compiler to stand between two of your

[swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

Hello Swift community, The review of SE-0153 "Compensate for the inconsistency of @NSCopying's behaviour" begins now and runs through February 22, 2017. The proposal is available here:

Re: [swift-evolution] Sequence/Collection Enhancements

> On Feb 16, 2017, at 5:39 PM, Ben Cohen via swift-evolution > > wrote: > > Hi swift-evolution, > > Following up on Ted’s post regarding the opening up of stage 2, I’m starting > a thread to discuss additive algorithms for Sequence

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I might(?) agree with others that `constexpr` might overlap but be ultimately different from `pure`. However, to me `constexpr` is more interesting because it would provide a potential macro language. As for syntax, while I think that matters less, I suspect trying to find why code isn't working

Re: [swift-evolution] Swift 4, stage 2 starts now

> On Feb 16, 2017, at 4:18 PM, Ted Kremenek via swift-evolution > wrote: > > Stage 2 > > With ABI stability well-understood and many of the stage 1 goals underway, it > is time to open up Swift 4 stage 2 to expand the scope of proposals to be > considered. > >

Re: [swift-evolution] [Pitch] Typed throws

On Fri, Feb 17, 2017 at 4:46 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote: > > I suggest we need to find a way to shorten the list of the possible error > types with a

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Second is better, but still looks ugly (no offense). I personally am totally ok with auto determination for most cases. Explicit case doesn't sound to me so widely used. I agree an explicit form might be of use in some rare scenarios and as long there is a possibility to define the purity (even in

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution >> wrote: >> >> Personally I feel enforced encapsulation of implementation detail to the

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 4:17 PM, Daniel Leping wrote: > > I don't think I can (fully) agree with you, because a closure purity is not > something you "define". It's rather what you use inside. Though I totally > understand your concern and a wish to have localized

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution > wrote: > > Personally I feel enforced encapsulation of implementation detail to the > latter group is less important than the former, and can be handled by > convention. Whereas other users of your

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I don't think I can (fully) agree with you, because a closure purity is not something you "define". It's rather what you use inside. Though I totally understand your concern and a wish to have localized errors. However, I think it's totally consistent if you use a full form in a way: { (a) => B

Re: [swift-evolution] final + lazy + fileprivate modifiers

> No, sorry, I don't agree with you. > Current situation forces us to generate huge source files or write each > type in its own submodule/file. IMO it is very naturally to have a need to > protect access to some details *even* in the same file(please find David > Sweeris's answer in previous

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 4:05 PM, Daniel Leping wrote: > > I personally like a lot => syntax for several reasons: > 1. Consistent > 2. Enforced return type > > As for the closures, I don't think we need an indication here. If it calls > any impure function or captures a

Re: [swift-evolution] [Pitch] Typed throws

Here we go again... -1 On Fri, 17 Feb 2017 at 23:52 Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > On Feb 17, 2017, at 3:45 PM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution <

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I personally like a lot => syntax for several reasons: 1. Consistent 2. Enforced return type As for the closures, I don't think we need an indication here. If it calls any impure function or captures a variable from outside - it's impure by definition. The compiler should decide if a closure can

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Fri, Feb 17, 2017 at 3:46 PM, Charlie Monroe wrote: > > On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu wrote: > >> On Fri, Feb 17, 2017 at 12:45

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 3:45 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution >> > wrote: >> >> I suggest we need to find a way to shorten

Re: [swift-evolution] [Pitch] Typed throws

I meant to say “… more than one throwing error type …” --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 22:48:35, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: No actually not, it was made up by the assumption that the proposed syntax would have more than one throwing

Re: [swift-evolution] [Pitch] Typed throws

No actually not, it was made up by the assumption that the proposed syntax would have more than one throwing that which was clarified by others to be incorrect. ;) Thanks again for clarification. --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 22:45:35, Joe Groff

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution > wrote: > > I suggest we need to find a way to shorten the list of the possible error > types with a the help of typeallias > > extension MyError1: Error { ... } > extension MyError2: Error { ... }

Re: [swift-evolution] [RFC][Proposal] Ease restrictions on protocol nesting

Anybody from core-team able to weigh in: do we want to keep this rule of not allowing parametrised protocols (in which case nesting is "trivial" - capturing is not allowed, only one protocol exists, so it's just namespacing), or is this something which should be deferred? If

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution > wrote: > > Out of curiosity, what are the benefits to being able to define that a > closure must be pure as a parameter/type definition, as opposed to defining a > particular closure to being pure

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Out of curiosity, what are the benefits to being able to define that a closure must be pure as a parameter/type definition, as opposed to defining a particular closure to being pure while being passed? What guarantees does it give you as the caller of the closure? Thanks, Jon > On Feb 16,

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

Hi Ted, Today I learned about https://esdiscuss.org/ which is like an archiver viewer for disc...@mozilla.org pipermail mailing list All their code is at https://github.com/esdiscuss This still preserves pipermail as the one source of

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

Hi Charles, If Swift code were to send NSNotFound to a method that took a nullable NSArrayIndex, under this example, one of two things could happen: 1.) The Swift compiler fails with a fix-it to use nil instead. 2.) The value is passed as-is and Objective-C handles it as usual. My preference

Re: [swift-evolution] [Pitch] Typed throws

Several proposals will follow this one: allowing multiple error types, removing Error, replacing rethrows, etc. Those topics are more controversial, but fortunately for them, they mostly add on top of the core feature being discussed. So IMO, if a detail can be split into its own proposal, we

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

> On Feb 13, 2017, at 9:33 PM, Jeff Kelley via swift-evolution > wrote: > > Hi all, > > I don’t have a formal proposal written up yet, but in my continued > quest to make better-annotated Objective-C code, I had an idea for bridging > nil with primitives.

Re: [swift-evolution] [Pitch] Typed throws

Wouldn’t that mean that you couldn’t use your Swift library in Objective-C anymore, at least the error type as an NSError? --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 21:16:57, Tino Heth (2...@gmx.de) schrieb: I thought it was going to be any one subtype of Error, be it a

Re: [swift-evolution] [Pitch] Typed throws

I disagree with that, it works if you only have a single function parameter type that throws an error, but if there are more than one inferring the type won’t be possible anymore: func foo(_: () throws(T) -> Void, _: () throws(S) -> Void) rethrows(S) (here, we’re assuming that T is handled

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

I would really like to see a nicer way of having Int? Exported to objc. Right now it kind of forces to use NSNumber which may be fine in the objc side but makes swift uglier, unless you want to write that code in a wrapper which doesn't scale really well Sent from my iPad > On 15 Feb 2017,

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 11:50 AM, Adrian Zubarev via swift-evolution > wrote: > > Sorry, I couldn’t follow every thread. I simply couldn’t get that fact from > the given context of the first post by Anton. :) Just forget everything I > mentioned about typealias,

Re: [swift-evolution] [Pitch] Typed throws

> I thought it was going to be any one subtype of Error, be it a struct, an > enum, or a protocol existential, or Error itself. Imho we should remove the restriction that you can only throw Error-conforming types if typed throws are added: It's a compatibility feature, and if you manually

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 17, 2017, at 2:51 PM, Xiaodi Wu wrote: > What a read! Two questions off the bat: > > 1. Any preliminary estimates as to what the performance cost of dynamic > enforcement is shaping up to be, at least in an initial implementation? It'd > have a direct impact on

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 11:25 AM, Vladimir.S wrote: > > On 17.02.2017 20:16, David Sweeris via swift-evolution wrote: >> >> >> >> Sent from my iPhone >>> On Feb 17, 2017, at 01:02, Rien wrote: >>> >>> On 17 Feb 2017, at 03:36, David Sweeris via

Re: [swift-evolution] [Manifesto] Ownership

What a read! Two questions off the bat: 1. Any preliminary estimates as to what the performance cost of dynamic enforcement is shaping up to be, at least in an initial implementation? It'd have a direct impact on how "opt-in" the additional tools really are. 2. Without the intention of

Re: [swift-evolution] [Pitch] Typed throws

Sorry, I couldn’t follow every thread. I simply couldn’t get that fact from the given context of the first post by Anton. :) Just forget everything I mentioned about typealias, because it was based on the assumption of an error list. Anyways +1 for typed throws. The syntax throws(T) and

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

> On Feb 17, 2017, at 1:42 PM, Charles Srstka via swift-evolution > wrote: > > - Much better performance. In my testing, updating the completedUnitProperty, > with something observing it, takes 1.04 seconds on my 2013 Retinabook, > compared with NSProgress’s 52.91

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 1:42 PM, Adrian Zubarev via swift-evolution > wrote: > > So the typed throws are going to be limited to a single error type, is that > the direction we're heading to? Yes, this topic was discussed thoroughly last year. > > -- > Adrian

Re: [swift-evolution] [Pitch] Typed throws

So the typed throws are going to be limited to a single error type, is that the direction we're heading to? --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 20:39:12, Anton Zhilin (antonyzhi...@gmail.com) schrieb: In this case, you’d better create a new error type, which includes

[swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

I’ve been working on a replacement for Progress (NSProgress) for use in my own code for a while now. It hasn’t been extensively battle-tested yet, but for the time being it seems to work. The full code for it is at https://github.com/CharlesJS/CSProgress

Re: [swift-evolution] [Pitch] Typed throws

In this case, you’d better create a new error type, which includes all the cases of those errors: // FileNotFoundError and WrongFormat are Error-s struct PreferencesError : Error { init(_: FileNotFoundError) init(_: WrongFormat) // ... } func readPreferences()

Re: [swift-evolution] [Pitch] Typed throws

Sorry I meant “recover from MyError (protocol)”. --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 20:30:35, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: The function that throws MyError might contain your error enum (or other types in general), but you would have to

Re: [swift-evolution] [Pitch] Typed throws

The function that throws MyError might contain your error enum (or other types in general), but you would have to recover from MyType to the dynamic type first. --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 20:26:48, Xiaodi Wu (xiaodi...@gmail.com) schrieb: On Fri, Feb 17,

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 1:24 PM, Xiaodi Wu via swift-evolution > wrote: > > Let's not bring bikeshedding the commonly proposed and rejected union > spelling into this. > Typed throws would be a nice addition, assuming that the core team finds it > in scope for phase

Re: [swift-evolution] [Pitch] Typed throws

On Fri, Feb 17, 2017 at 1:22 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > Sure thing, but that’s not what I was asking about. Kevin made a protocol > that conforms to Error where all the his enums conformed to MyError > protocol. That way we’re losing all enum

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

There shouldn't be a need for a third arrow with regard to purity. Impure encompasses pure in that there is simply no guarantee of purity with an impure function. You should be able to use a pure function in place of an impure function without any issue whatsoever. On Fri, Feb 17, 2017 at 1:35

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> On Feb 17, 2017, at 10:51 AM, Xiaodi Wu via swift-evolution > wrote: > > There's nothing, afaik, which stands in the way of that syntax today. The > proposal is to extend the standard library to add syntax for a math library. > The idea of having a core math

Re: [swift-evolution] final + lazy + fileprivate modifiers

On 17.02.2017 20:16, David Sweeris via swift-evolution wrote: Sent from my iPhone On Feb 17, 2017, at 01:02, Rien wrote: On 17 Feb 2017, at 03:36, David Sweeris via swift-evolution wrote: On Feb 16, 2017, at 14:34, Slava Pestov via

Re: [swift-evolution] [Pitch] Typed throws

Let's not bring bikeshedding the commonly proposed and rejected union spelling into this. Typed throws would be a nice addition, assuming that the core team finds it in scope for phase 2. It seems only logical that any type can be thrown (i.e. conforms to Error) should be permitted to be listed in

Re: [swift-evolution] [Pitch] Typed throws

Sure thing, but that’s not what I was asking about. Kevin made a protocol that conforms to Error where all the his enums conformed to MyError protocol. That way we’re losing all enum cases and are not really a step further as before. --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu wrote: > On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S wrote: > >> On 17.02.2017 20:48, Xiaodi Wu wrote: >> >>> What you are really asking for is a way of flexibly designating a "unit >>> of >>> code" within a

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 11:12 AM, Adrian Zubarev via swift-evolution > wrote: > > Is the throwing type always a protocol? In your example it is, but is this > going to be always the case? > I think right now, there’s a bit of compiler magic in that you can only throw

Re: [swift-evolution] [Pitch] Typed throws

That’s what I thought too. That’s also the case I showed a simple example how we could solve the giant list with a typealias even if the pipe | operator would be exclusive for anything that conforms to Error. --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 20:16:30, Anton Zhilin

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I'm really not sold about the ~> operator, as it would be easy to miss. Swift is known and loved for the expressiveness of the language, using that operator doesn't help with that. On another hand, I agree that this is the sexiest, less intrusive solution. On 17 févr. 2017 13:36 -0500, Adrian

Re: [swift-evolution] [Pitch] Typed throws

2017-02-17 22:12 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: Is the throwing type always a protocol? In your example it is, but is this > going to be always the case? > I thought it was going to be any one subtype of Error, be it a struct, an enum, or a protocol

Re: [swift-evolution] [Pitch] Typed throws

Is the throwing type always a protocol? In your example it is, but is this going to be always the case? --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 20:08:38, Kevin Nattinger (sw...@nattinger.net) schrieb: protocol MyError: Error {} enum MyFooError: MyError { … } enum

Re: [swift-evolution] final + lazy + fileprivate modifiers

On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S wrote: > On 17.02.2017 20:48, Xiaodi Wu wrote: > >> What you are really asking for is a way of flexibly designating a "unit of >> code" within a module, for which the general solution is submodules. The >> objection is that, instead

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 17, 2017, at 10:45 AM, Anton Zhilin via swift-evolution > wrote: > > Now this is on-topic, I guess. > Last time we stopped at John McCall’s syntax: > > extension MyError: Error { ... } > > func foo() throws(MyError) -> MyResult > It’s conservative and

Re: [swift-evolution] [Pitch] Typed throws

protocol MyError: Error {} enum MyFooError: MyError { … } enum MyBarError: MyError { … } func baz() throws(MyError) > On Feb 17, 2017, at 11:03 AM, Adrian Zubarev via swift-evolution > wrote: > > I suggest we need to find a way to shorten the list of the possible

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> On Feb 17, 2017, at 10:51 AM, Xiaodi Wu wrote: > > > On Fri, Feb 17, 2017 at 12:46 PM, David Sweeris > wrote: > >> On Feb 17, 2017, at 10:38 AM, Abe Schneider via swift-evolution >>

Re: [swift-evolution] [Pitch] Typed throws

I suggest we need to find a way to shorten the list of the possible error types with a the help of typeallias extension MyError1: Error { ... } extension MyError2: Error { ... } extension MyError3: Error { ... } typealias MyErrors = MyError1 | MyError2 | MyError3 func foo() throws(MyErrors)

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

On Fri, Feb 17, 2017 at 12:46 PM, David Sweeris wrote: > > On Feb 17, 2017, at 10:38 AM, Abe Schneider via swift-evolution < > swift-evolution@swift.org> wrote: > > If I read Nicolas's post correctly, I think he's more arguing for the > ability to create syntax that allows

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

On Fri, Feb 17, 2017 at 12:34 PM, Nicolas Fezans wrote: > > > If you're simply looking for elementwise multiply without performance > > requirements, map(*) is a very succinct spelling. > > Yes, it is (combined with zip), but: > 1) zip map will not enforce same size

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> On Feb 17, 2017, at 10:38 AM, Abe Schneider via swift-evolution > wrote: > > If I read Nicolas's post correctly, I think he's more arguing for the > ability to create syntax that allows Swift to behave in a similar way > to Numpy/Matlab. While Swift already does

[swift-evolution] [Pitch] Typed throws

Now this is on-topic, I guess. Last time we stopped at John McCall’s syntax: extension MyError: Error { ... } func foo() throws(MyError) -> MyResult It’s conservative and prevents visual ambiguity with extra parentheses. If we (somewhat) agree on this, then submitting a proposal will be

Re: [swift-evolution] final + lazy + fileprivate modifiers

On 17.02.2017 20:48, Xiaodi Wu wrote: What you are really asking for is a way of flexibly designating a "unit of code" within a module, for which the general solution is submodules. The objection is that, instead of tackling that issue, these are suggestions to invent ad-hoc units of code (scope

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

If I read Nicolas's post correctly, I think he's more arguing for the ability to create syntax that allows Swift to behave in a similar way to Numpy/Matlab. While Swift already does allow you to define your own operators, the main complaint is that he can't define the specific operators he would

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> If you're simply looking for elementwise multiply without performance > requirements, map(*) is a very succinct spelling. Yes, it is (combined with zip), but: 1) zip map will not enforce same size (which shall be done to fail hard early), nor allow to combine with an array of a single element,

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 9:48 AM, Xiaodi Wu via swift-evolution > wrote: > > What you are really asking for is a way of flexibly designating a "unit of > code" within a module, for which the general solution is submodules. The > objection is that, instead of tackling

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

That autocorrection sometimes :/ Purity could easily be expressed through the arrow, plus it enforces you to have a return type (other than Void). --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 19:27:12, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: Purity could be

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 17, 2017, at 9:51 AM, André “Zephyz” Videla via swift-evolution > wrote: > >> But given the scope capturing nature of closures I was actually wondering if >> this 'purity' should be applied to closures. > I think It should, pure closure cannot have outside

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Who said that pure functions should be newcomer friendly? Swift attributes are way at the end of the swift’s book. Using the -> arrow at first won’t break anything. If one would optimize some functions by annotating them to be pure, the change to something like ~> would be really easy. IMHO

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Just let @pure func foo(_ f: (Int) -> Int) -> Int be the same as those two combined: @pure func foo(_ f: @pure (Int) -> Int) -> Int func foo(_ f: (Int) -> Int) -> Int No need for anything like “re-pure” or ≃>. ​ ___ swift-evolution mailing list

  1   2   >