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

Hi, I think a func such as clamped would be helpful. to be frank, I had made some mistakes when trying to compose min and max correctly. Robert Bennett via swift-evolution 于2017年3月11日周六 下午1:35写道： > I can't argue with that. I guess I was really only opposed to using

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

On Fri, Mar 10, 2017 at 4:44 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 10, 2017, at 8:49 AM, Joe Groff wrote: > > > > I think there's a more powerful alternative design you should also > consider. If the protocol looked like this:

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

I can't argue with that. I guess I was really only opposed to using the half-open range for Double and other theoretically non-discrete types, for the reasons I listed. I have no objections to clamping with a half-open Integer range; I just hadn't considered further restricting the Bound of the

[swift-evolution] Assignment to 'let' constant in defer blocks

Is this a feature or a bug? class Foo { let bar: Int init?(someConditionBasedOnInputData: Bool) { var localBar: Int = 0 defer { bar = localBar //Cannot assign to property: 'bar' is a 'let' constant } if someConditionBasedOnInputData {

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

> On Mar 10, 2017, at 8:04 PM, Robert Bennett via swift-evolution > wrote: > > I really like this proposal, and think that it does have a place in Swift 4. > Two quick notes in light of the discussion: first, I think it should be > called clamped, not clamp;

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

I really like this proposal, and think that it does have a place in Swift 4. Two quick notes in light of the discussion: first, I think it should be called clamped, not clamp; second, I think it should only take ClosedRange. More on those later, but first I'll respond to the six questions

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

I want to thank everyone so much for the feedback. I really would like to propose a draft of this in the near future given that from reading this thread it seems that a good amount of people seem to want a `clamp(to:)` function of some kind but are still not settled on the exact implementation

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

This works because your properties are read-only, thus allowed to be covariant. If you add a setter, the compiler will complain. -DW > On Mar 10, 2017, at 5:33 AM, Anton Zhilin via swift-evolution > wrote: > > Looks like a compiler bug, since it works with classes:

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

The getter is covariant while the setter is contravariant. The result is read/write properties are invariant. Objective-C basically considers declared types to be advisory (to generate compiler warnings). In reality, both delegate properties are of type ‘id’, with type issues surfacing at

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

On Fri, Mar 10, 2017 at 6:29 PM, James Froggatt wrote: > > On 11 Mar 2017, at 00:21, James Froggatt wrote: > > > On 11 Mar 2017, at 00:05, Xiaodi Wu wrote: > > Some days ago, Ben Cohen laid out the criteria for helper functions

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

> On Mar 10, 2017, at 8:49 AM, Joe Groff wrote: > > I think there's a more powerful alternative design you should also consider. > If the protocol looked like this: > > protocol ExpressibleByStringInterpolation: ExpressibleByStringLiteral { > associatedtype LiteralSegment:

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

> On 11 Mar 2017, at 00:21, James Froggatt wrote: > > >> On 11 Mar 2017, at 00:05, Xiaodi Wu wrote: >> >> Some days ago, Ben Cohen laid out the criteria for helper functions in the >> Standard Library. Here's some of his very enlightening text and

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

> On 11 Mar 2017, at 00:05, Xiaodi Wu wrote: > > Some days ago, Ben Cohen laid out the criteria for helper functions in the > Standard Library. Here's some of his very enlightening text and the six > criteria: > >> The operation needs to carry its weight. Even once we

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

Hi Rob, I think we could actually do that (and cause the same bug) with the derived classes Anton mentioned, which means the behaviour is inconsistent, despite the perhaps safety. - Rod > On 11 Mar 2017, at 6:32 am, Rob Mayoff wrote: > >> On Fri, Mar 10, 2017 at 6:08 AM, Rod

Re: [swift-evolution] Infer types of default function parameters

+1 from me, since it's more convenient and an opt-in feature. I'm not sure it's in scope for Swift 4, though, as a purely additive change. Begin Message Group: gmane.comp.lang.swift.evolution MsgID:

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

This topic caught my attention. I support the idea, I'm currently using an extension for this. >>Should “16.clamped(to: 0..<10)” produce 9 or 10? >9 Sounds good. >>What about “16.clamped(to: 0..<0)”, which is an empty range? >For `Int`? Crash (which, until about 5 minutes ago, is what I

Re: [swift-evolution] Infer types of default function parameters

-1 from me. I prefer explicitness at function boundaries. On Fri, Mar 10, 2017 at 4:55 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 10, 2017, at 1:40 PM, Kilian Koeltzsch via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi all, > > I sent the

Re: [swift-evolution] Infer types of default function parameters

> On Mar 10, 2017, at 1:40 PM, Kilian Koeltzsch via swift-evolution > wrote: > > Hi all, > > I sent the message below to swift-users@ ~a day ago, but this might be a > better place to ask and gather some discussion. It is a rather minor > suggestion and I'm just

[swift-evolution] Infer types of default function parameters

Hi all, I sent the message below to swift-users@ ~a day ago, but this might be a better place to ask and gather some discussion. It is a rather minor suggestion and I'm just looking for some opinions. Declaring a function that has default parameters currently looks like this: func foo(bar:

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

> On Mar 10, 2017, at 11:32 AM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > On Fri, Mar 10, 2017 at 4:16 AM, David Sweeris via swift-evolution > > wrote: > > I’m ok with doing it as an

Re: [swift-evolution] Additive proposals

Hi Adrian, Thanks for bringing this up. We discussed this amongst the core team and have the following guidance that may help. It’s worth noting that some additive proposals are currently in scope, where they are aligned with the themes set out for Swift 4. For example, additive proposals for

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

> On Mar 10, 2017, at 11:27 AM, David Waite > wrote: > >> >> On Mar 10, 2017, at 9:49 AM, Joe Groff via swift-evolution >> wrote: >> >> Having ExpressibleByStringInterpolation refine ExpressibleByStringLiteral >> makes sense. I

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

On Fri, Mar 10, 2017 at 6:08 AM, Rod Brown via swift-evolution < swift-evolution@swift.org> wrote: > Hi everyone. I found something odd that seems baked into how Cocoa Touch > does protocols, but Swift cannot model it: > > > @interface UIScrollView: UIView > > @property (weak, nonatomic) id

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

On Fri, Mar 10, 2017 at 4:16 AM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > I’m ok with doing it as an extension on `Comparable`, although we should > add an overload for regular ranges, too. > > - Dave Sweeris > How would the semantics of that work? Should

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

> On Mar 10, 2017, at 9:49 AM, Joe Groff via swift-evolution > wrote: > > Having ExpressibleByStringInterpolation refine ExpressibleByStringLiteral > makes sense. I think there's a more powerful alternative design you should > also consider. If the protocol looked

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

Having ExpressibleByStringInterpolation refine ExpressibleByStringLiteral makes sense. I think there's a more powerful alternative design you should also consider. If the protocol looked like this: protocol ExpressibleByStringInterpolation: ExpressibleByStringLiteral { associatedtype

Re: [swift-evolution] [Discussion] Static methods as global functions

> On 10 Mar 2017, at 13:36, Derrick Ho wrote: > > -1 Thanks for being so specific in a discussion thread 樂 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

-1 Something like `42` will make things confusing. On Thu, Mar 9, 2017 at 5:53 PM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 9, 2017, at 04:40, Ross O'Brien via swift-evolution < > swift-evolution@swift.org> wrote: > > I could see a purpose for identifiers

Re: [swift-evolution] [Discussion] Static methods as global functions

-1 On Fri, Mar 10, 2017 at 6:18 AM Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > So the topic of global functions like min/max came up on the thread about > adding a standard clamp method, and it got me to thinking whether there was > a better way to define most global

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

Looks like a compiler bug, since it works with classes: class Base {}class Derived : Base {} class A { var x: Base? { return Base() } } class B : A { override var x: Derived? { return Derived() } } ​ ___ swift-evolution mailing list

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

I kinda feel this is somehow related: http://discourse.natecook.com/t/pitch-return-a-subclass-for-a-protocol-method-without-the-need-for-an-associatedtype/2355 It would be really handy to be able to override any type A with another type B where the relationship is B : A. --  Adrian Zubarev

[swift-evolution] Specified Protocol Conformances in Subclasses

Hi everyone. I found something odd that seems baked into how Cocoa Touch does protocols, but Swift cannot model it: @interface UIScrollView: UIView @property (weak, nonatomic) id delegate; @end @interface UITableView: UIScrollView @property (weak, nonatomic) id delegate; @end @protocol

[swift-evolution] [Discussion] Static methods as global functions

So the topic of global functions like min/max came up on the thread about adding a standard clamp method, and it got me to thinking whether there was a better way to define most global methods. Currently for example there are two global functions min and max; very useful, and don't make much

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

​Dave, ​ > I’m ok with doing it as an extension on `Comparable`, although we should > add an overload for regular ranges, too. ​Yeah, I completely agree and for now I'll drop the topic of removing the global definitions for min / max​. So the aim of this proposal would be to add `clamp` to

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

> On Mar 10, 2017, at 1:13 AM, David Sweeris wrote: > > >> On Mar 10, 2017, at 12:22 AM, Jaden Geller via swift-evolution >> > wrote: >> >>> On Mar 9, 2017, at 11:20 PM, Nicholas Maccharoli via swift-evolution

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

> On Mar 10, 2017, at 1:12 AM, Nicholas Maccharoli via swift-evolution > wrote: > > Sorry for sidetracking by talking about dumping the global definitions of > `min` and `max` but if that could be done and it were decided by the swift > community that adding a

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

> On Mar 10, 2017, at 12:22 AM, Jaden Geller via swift-evolution > wrote: > >> On Mar 9, 2017, at 11:20 PM, Nicholas Maccharoli via swift-evolution >> > wrote: >> >> Nevin, >> >> Yeah I think this works

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

Sorry for sidetracking by talking about dumping the global definitions of `min` and `max` but if that could be done and it were decided by the swift community that adding a clamp function would be appropriate, I guess with the array implementations of min / max the clamp function might be

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

> On Mar 9, 2017, at 11:20 PM, Nicholas Maccharoli via swift-evolution > wrote: > > 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