Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

+1 for the fix. Solid and straightforward. On Thu, Mar 9, 2017 at 9:32 AM, Rod Brown via swift-evolution < swift-evolution@swift.org> wrote: > There has been a lot of discussion around this design decision. > Personally, I’m with you: this should be allowed. Protocol extensions > should be

Re: [swift-evolution] Swift 4: Support for static libs / modular development.

I'd like to add a +1 for this request/discussion starter. We're on the same boat, with 70+ dynamic libraries, facing the same challenges as Raphael mentioned. Jacek Suliga | Flagship Infra On Fri, Feb 17, 2017 at 10:02 AM, Raphael Sebbe via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

I’d be on board with an extension of Comparable so you could write “16.clamped(to: 0...10)”. Something along the lines of: extension Comparable { func clamped(to range: ClosedRange) -> Self { return max(range.lowerBound, min(self, range.upperBound)) } } Nevin

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

I have a change ready and can turn it into a PR. Jordan mentioned in the bug that this would require a SE proposal, but looking at this as a bug in the current implementation rather than a change in the language makes sense. It certainly is trivial enough, and doesn't change any semantics, so I'll

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

There has been a lot of discussion around this design decision. Personally, I’m with you: this should be allowed. Protocol extensions should be defaults, nothing more. The rationale mentioned in Swift Evolution for discouraging this behaviour tends to be that if you conform to the protocol,

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

> On 28 Feb 2017, at 17:05, Daniel Dunbar via swift-evolution > wrote: > > >> On Feb 28, 2017, at 12:28 AM, Jens Nerup > > wrote: >> >> Hello Daniel, >> >> In general I’m really happy with the changes in the proposal

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

In other languages I normally have a method with a variable number of arguments and another one taking an array. Then one typically ends up calling the other. If we had implicit splatting I imagine it would reduce such methods to only one. However if implicit splatting were to cause problems

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

> On Mar 9, 2017, at 12:31 AM, Xiaodi Wu wrote: > > On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan > wrote: > Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to > incorporate some of the responses into the

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On Mar 9, 2017, at 10:43 AM, Ricardo Parada wrote: > > In other languages I normally have a method with a variable number of > arguments and another one taking an array. Then one typically ends up calling > the other. > > If we had implicit splatting I imagine it would

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

> On Mar 9, 2017, at 5:59 AM, Matthew Johnson via swift-evolution > wrote: > > I have argued repeatedly that enum cases play two distinct roles (and > sometimes a third in the future). We need to embrace all of these roles. > This proposal primarily normalizes

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

cc’ing Xiaodi > On Mar 9, 2017, at 1:53 PM, Joe Groff wrote: > > >> On Mar 8, 2017, at 7:09 PM, Daniel Duan via swift-evolution >> > wrote: >> >> Hi everyone, >> >> Here’s revision 2 of SE-0155. I’d love some

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

> On Mar 8, 2017, at 22:34, Ankit Aggarwal wrote: > > >> +1, although I don’t know why we're supporting this: >> // 1.5.8 ..< 2.0.0 >> .package(url: "/SwiftyJSON", from: "1.5.8"), >> when, at least as far as I can tell, this: >> // 1.5.8 ..< 2.0.0 >> .package(url:

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

> On Mar 8, 2017, at 7:09 PM, Daniel Duan via swift-evolution > wrote: > > Hi everyone, > > Here’s revision 2 of SE-0155. I’d love some feedback before going into > re-review. > > Note the “anonymous case” feature is not in this proposal. I found the > motivation

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

> On Mar 9, 2017, at 11:48 AM, Daniel Duan wrote: > >> >> On Mar 9, 2017, at 12:31 AM, Xiaodi Wu > > wrote: >> >> On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan > > wrote: >> Thanks for

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

> On Mar 9, 2017, at 04:40, Ross O'Brien via swift-evolution > wrote: > > I could see a purpose for identifiers which started numbers but weren't > entirely numerical. > e.g. > enum Dimensions { case `2D`, `3D` } > enum DiceRoll { case d6, `2d6` } > func roll(dice:

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

> On 9 Mar 2017, at 23:32, Rick Ballard wrote: > > > Proposal link: > >> > >> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md > >> > >>

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

> On 7 Mar 2017, at 21:53, Rick Ballard via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0158 Package Manager Manifest API Redesign" begins now and > runs through March 13, 2017. The proposal is available here: > > >

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

> On 9 Mar 2017, at 23:48, Karl Wagner wrote: > > >> On 9 Mar 2017, at 23:32, Rick Ballard > > wrote: >> >> > Proposal link: >> >> >> >>

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

> Proposal link: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md > On Mar 9, 2017, at 3:02 PM, Karl Wagner wrote: > >> On 9 Mar 2017, at 23:48, Karl Wagner >

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

> Proposal link: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md >> >> > On Mar 9, 2017, at 2:30 PM, Karl Wagner

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

Here’s an updated version with hopefully the correct content. The “overloaded” case feature has been removed and is discussed in the "alternatives considered" section. # Normalize Enum Case Representation * Proposal: [SE-0155][] * Authors: [Daniel Duan][], [Joe Groff][] * Review Manager:

[swift-evolution] Add a `clamp` function to Algorithm.swift

Swift Evolution, Having a`clamp` function available in the standard library would complement `min` and `max` really well. I mentioned this before when the discussion for Swift 4 was still in stage 1, but now that stage 2 has started I thought it might be worth while to bring up again. Still

Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

> On Mar 9, 2017, at 5:37 PM, Nicholas Maccharoli via swift-evolution > wrote: > > Swift Evolution, > > Having a`clamp` function available in the standard library would complement > `min` and `max` really well. > > I mentioned this before when the discussion for

Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

Nevin, Yeah I think this works well as an extension on `Comparable`, `foo.clamped(to: 1...100)` seems pretty natural. Why not go one step further and move the versions of min, max that take two arguments on over to `Comparable` as a protocol extension? Perhaps something like this? extension

[swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

...is the title of a proposal I wrote today. The full proposal is available at: But the tl;dr is that, if you write this:

Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

Dave, Thanks for the feedback! Yes, there is no explicit need to make `clamp` a global function, and the extension you proposed would work just fine I think. `CountableClosedRange` already provides a `clamped(to:)` method but that does not suit the use case I was thinking of wanting to receive

Re: [swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

> On Mar 9, 2017, at 6:18 PM, Brent Royal-Gordon wrote: > > ...is the title of a proposal I wrote today. The full proposal is available > at: > > >

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan wrote: > Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to > incorporate some of the responses into the proposal. > > On Mar 8, 2017, at 9:56 PM, Xiaodi Wu wrote: > > The rendered version

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

That’s correct, thanks for the correction. The rule only applies to parameters with argument labels. But still, we’d lost this guarantee of self-documenting, type-safe non-emptiness if arbitrary arrays can be passed to variadic parameters with argument labels. R+ > On 8 Mar 2017, at 23:42,

Re: [swift-evolution] Custom Literals

I'm quite positive we need it. The question is in which way. On Thu, 9 Mar 2017 at 2:24 David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > The conversation kinda died out over the new year, and a quick search > didn’t come up with an answer... Did we decide that adding

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

My point would be to have a exact set of possible numerical cases. The issue with numerical cases is that they don’t have to be ordered and they could also be overlapping with other subsystems (by subsystem I mean a subsystem of your particular project). Even if we had the ability to limit the

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

> On Mar 9, 2017, at 12:06 AM, David Hart wrote: > > >> On 9 Mar 2017, at 08:07, Daniel Duan via swift-evolution >> wrote: >> >> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to >> incorporate some of the responses into

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

I think the fact that the type checker permits ‘final’ to appear inside protocol extensions is an oversight and this probably does not even warrant a proposal. I don’t think allowing this was ever part of the conceptual model of protocol extensions at any point in time (if you recall they were

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

> On 9 Mar 2017, at 08:07, Daniel Duan via swift-evolution > wrote: > > Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to > incorporate some of the responses into the proposal. > > On Mar 8, 2017, at 9:56 PM, Xiaodi Wu

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

I could see a purpose for identifiers which started numbers but weren't entirely numerical. e.g. enum Dimensions { case `2D`, `3D` } enum DiceRoll { case d6, `2d6` } func roll(dice: DiceRoll) -> Int { ... } roll(.`2d6`) I'm not sure I see one for identifiers which are entirely numerical. Ross

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

Sent from my iPad > On Mar 9, 2017, at 2:31 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan wrote: >> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to >> incorporate some of the

Re: [swift-evolution] [Draft] Anonymous Enum Cases

+1. Combining this with overloaded cases will be very nice for some kinds of enums. Sent from my iPad > On Mar 8, 2017, at 9:09 PM, Daniel Duan via swift-evolution > wrote: > > Hi all, > > During review for the first revision of SE-0155, Dave Abraham suggested

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

Sent from my iPad > On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution > wrote: > > I think the fact that the type checker permits ‘final’ to appear inside > protocol extensions is an oversight and this probably does not even warrant a > proposal. I

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On Feb 26, 2017, at 10:00 PM, Derrick Ho via swift-evolution > wrote: > > foo(["a", "b", "c"] as String...) I like this ___ swift-evolution mailing list swift-evolution@swift.org