Re: [swift-evolution] [Pitch] Add namespacing to associatedTypes

> Types associated with a protocol are not namespaced by the protocol, but > rather by the protocol's adopters. As such, when two protocols declare a > common associatedType, adoption of those protocols introduces undesirable > ambiguity. I don't think there's much of a point solving this just

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

Yet another inconsistency in this area (for people who care about them) While the 'while {}' does not support trailing closures, the 'repeat {} while' does support them. So, will the folks against supporting them in 'guard' ask for a change to drop the support in the 'repeat {} while'? Dany >

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

(Sorry, sent without finishing a sentence.) >> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md > >> But then, these *are* intended to be full-width type conversions, >> are they not? Why not these: >> >> init?(_ source: ObjectiveCType) >>

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 5:22 PM, Dave Abrahams via swift-evolution > wrote: > I don't think that's obvious at all, because 0 ≮ 10 Points brought up elsewhere: * A range does not have direction, it is is an area of variation between lower and upper limits. * A range

[swift-evolution] Notes from Swift core team 2016-04-05 design discussion

To help keep proposals moving forward, the Swift core team has set aside some time specifically for design discussions of upcoming proposals. Below are some rough notes from the yesterday's discussion. These are informal comments, intended to guide the proposals in directions that draw

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Erica Sadun wrote: >> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Apr 05 2016, Erica Sadun wrote: >> > >>>On Apr 5, 2016, at 1:54 PM, Dave

Re: [swift-evolution] deployment targets and frameworks

> On Apr 5, 2016, at 12:06 PM, Douglas Gregor wrote: > > I would not want this to be implicit behavior: it should be recorded in the > source with, e.g., > > @availability(iOS: 9.3) import YourCustomFramework > > so that it is clear that the imported declarations are

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 4:24 PM, Stephen Canon wrote: > >> On Apr 5, 2016, at 3:22 PM, Erica Sadun via swift-evolution >> > wrote: >> >>> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >>>

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 3:21 PM, Erica Sadun wrote: > > Please check to ensure that the changes I just made match your expectations: > > https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227 > That

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Xiaodi Wu wrote: > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams wrote: >> >> on Sat Apr 02 2016, Xiaodi Wu wrote: >> >>> [snip] >>> >>> Not included: >>> 1. I know Ranges are in flux, so I've held off on extending Range with

Re: [swift-evolution] Feature proposal: Range operator with step

Well, probably best to have another operator: 0..>(-10). We go from 0 to greater than -10. On Tue, Apr 5, 2016 at 5:22 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: >

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 3:22 PM, Erica Sadun via swift-evolution > wrote: > >> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >> on Tue Apr 05 2016, Erica Sadun wrote: >> >>> On Apr

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 4:22 PM, Erica Sadun via swift-evolution > wrote: > >> >> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Apr 05 2016, Erica Sadun wrote: >> >>>

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Apr 05 2016, Erica Sadun wrote: > >>On Apr 5, 2016, at 1:54 PM, Dave Abrahams >> wrote: >>IMO this: >> >>

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 4:17 PM, Timothy Wood wrote: > > >> On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution >> > wrote: >> >> What you're describing should be spelled `Self`, IMO. I think Tim intended >>

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Erica Sadun wrote: > On Apr 5, 2016, at 1:54 PM, Dave Abrahams > wrote: > IMO this: > > (-9...0).reverse() > > is better than > > stride(from: 0, to: -10, by: -1) > > What do you think? > > The

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution > wrote: > > What you're describing should be spelled `Self`, IMO. I think Tim intended > `#Self` to mean the *static* type the code is declared inside (which is the > same as Self unless you're in a

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

Updating. Gist here: https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227 -- E > On Apr 5, 2016, at 4:04 PM, Joe Groff wrote: > >> >> On Apr 5, 2016, at 3:02 PM, Erica Sadun wrote: >> >> As the discussion seems to be quieting down, I've

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 3:02 PM, Erica Sadun wrote: > > As the discussion seems to be quieting down, I've tried to summarize the > on-list discussion and distill it into a preliminary proposal draft. Please > let me know if this covers what you think it should or if I've

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 5, 2016, at 1:54 PM, Dave Abrahams wrote: > IMO this: > > (-9...0).reverse() > > is better than > > stride(from: 0, to: -10, by: -1) > > What do you think? The latter better reflects an author's actual intent. The former depends on implementation details,

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

As the discussion seems to be quieting down, I've tried to summarize the on-list discussion and distill it into a preliminary proposal draft. Please let me know if this covers what you think it should or if I've entirely missed the mark. (It wouldn't be the first time.) Regards, -- Erica

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Xiaodi Wu wrote: > Right. I would argue that `(a+s...b).striding(by: s).reversed` is a great deal > less readable than `stride(from: b, to: a, by: -s)`. And since the latter is > the > status quo, I would say that it's a point against restricting

Re: [swift-evolution] Feature proposal: Range operator with step

Right. I would argue that `(a+s...b).striding(by: s).reversed` is a great deal less readable than `stride(from: b, to: a, by: -s)`. And since the latter is the status quo, I would say that it's a point against restricting strides to the proposed syntax. On Tue, Apr 5, 2016 at 3:57 PM Dave

Re: [swift-evolution] Feature proposal: Range operator with step

Ha, yes, clearly. On Tue, Apr 5, 2016 at 4:00 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Tue Apr 05 2016, Xiaodi Wu wrote: > > > Certainly, for integer literals and strides of -1. > > > > I meant more generally that removal of

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Howard Lovatt wrote: > Yes I know what you are saying and I am suggesting changing that so that: > > (0 ... -9) and (0 ..< -10) > > Are both empty ranges rather than errors because they implicitly have a 'by' > of > 1. What are the startIndex

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

I think TOML is no-go as its readme says: Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly. And I agree about YAML: no parser, more work, and more complicated. JSON sounds like a sane format. > On 04 Apr 2016, at

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Xiaodi Wu wrote: > Certainly, for integer literals and strides of -1. > > I meant more generally that removal of stride(...) will eliminate the > possibility of striding to but not through arbitrary half-open intervals (a, > b], > where a < b, by

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Xiaodi Wu wrote: > Certainly, for integer literals and strides of -1. > > I meant more generally that removal of stride(...) will eliminate the > possibility of striding to but not through arbitrary half-open intervals (a, > b], > where a < b, by

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

on Mon Apr 04 2016, Joe Groff wrote: > Hello Swift community, > > The review of “Allow Swift types to provide custom Objective-C > representations” > begins now and runs through April 11, 2016. The proposal is available here: > >

Re: [swift-evolution] Feature proposal: Range operator with step

Yes I know what you are saying and I am suggesting changing that so that: (0 ... -9) and (0 ..< -10) Are both empty ranges rather than errors because they implicitly have a 'by' of 1. On Wednesday, 6 April 2016, Xiaodi Wu wrote: > Howard, the point I am raising is that

Re: [swift-evolution] Feature proposal: Range operator with step

Howard, the point I am raising is that `0...(-9)` is not valid Swift because the first, "lower" bound is enforced to be less than the second, "upper" bound. The problem is that with that restriction certain types of half-open intervals, namely those where the lower bound is the one being

Re: [swift-evolution] [Proposal] Custom operators

Added group version, "lessThan" problem can be solved nicely. `<`, `=`, `>` signs would be allowed there. > Should we allow "precedence(... equalTo ...)" for operators

Re: [swift-evolution] Feature proposal: Range operator with step

I much prefer (0 ... -9).by(-1) and (0 ..< -10).by(-1) On Wednesday, 6 April 2016, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Tue Apr 05 2016, Xiaodi Wu wrote: > > > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams > wrote: >

Re: [swift-evolution] Feature proposal: Range operator with step

> On 5 Apr 2016, at 20:54, Dave Abrahams via swift-evolution > wrote: > > IMO this: > > (-9...0).reverse() > > is better than > > stride(from: 0, to: -10, by: -1) > > What do you think? > > -- > Dave Are we absolutely certain that an operator could not be

Re: [swift-evolution] Feature proposal: Range operator with step

Certainly, for integer literals and strides of -1. I meant more generally that removal of stride(...) will eliminate the possibility of striding to but not through arbitrary half-open intervals (a, b], where a < b, by a negative increment, because there is no such thing as `a>..b` to express such

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 11:41 AM, Russ Bishop wrote: > > But if you don’t want subclasses to override it then why are you making it > internal/public in the first place? I'm wan’t talking about overriding it… In my earlier posts I was talking about subclasses being able to

Re: [swift-evolution] Feature proposal: Range operator with step

on Tue Apr 05 2016, Xiaodi Wu wrote: > On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams wrote: >> >> on Sat Apr 02 2016, Xiaodi Wu wrote: >> >>> [snip] >>> >>> Not included: >>> 1. I know Ranges are in flux, so I've held off on extending Range with >>> a striding(by:) method

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

> On Apr 5, 2016, at 11:36 AM, Russ Bishop wrote: > > >> On Apr 5, 2016, at 10:14 AM, Douglas Gregor > > wrote: >>> Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this Objective-C API:

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution > wrote: > > >> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution >> > wrote: >>> Would using another word or symbol fix that

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

> On Apr 5, 2016, at 10:14 AM, Douglas Gregor wrote: >> >>> Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this >>> Objective-C API: >>> >>> ObjCMutableFizzer* mutableFizzer; >>> >>> Which of these represents how it is imported? >>> >>> var

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

I too would like a #Self. In my (subjective, biased) experience, sufficiently descriptive type names are usually long enough to make working with static members painfully onerous. If there's still the risk of confusion (compile-time type versus runtime type), maybe #Self can be limited to

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

> On Apr 4, 2016, at 9:54 PM, Russ Bishop via swift-evolution > wrote: > >> >> On Apr 4, 2016, at 9:22 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> >>>

Re: [swift-evolution] deployment targets and frameworks

> On Apr 4, 2016, at 4:48 PM, Drew Crawford via swift-evolution > wrote: > > Suppose *Apple* ships a framework that is only supported in iOS 9.3. As a > direct consequence, the framework is only #available in iOS 9.3 or later. > > Suppose Jane links this framework

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 10:06 AM, Joe Groff via swift-evolution > wrote: > >> >> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution >> wrote: >> >> >>> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution >>>

[swift-evolution] [Pitch] Add namespacing to associatedTypes

Types associated with a protocol are not namespaced by the protocol, but rather by the protocol's adopters. As such, when two protocols declare a common associatedType, adoption of those protocols introduces undesirable ambiguity. Given the understandable propensity of developers to arrive at

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution > wrote: > > >> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution >> wrote: >>> Would using another word or symbol fix that problem? >> >> My preference would be for

Re: [swift-evolution] [Proposal] Custom operators

David Waite stated a major drawback of precedence groups. People will often create tiny precedence groups for their modules, and user will find that some of them should actually be the same. They will add precedenceEqualTo, but all these equivalent groups will still exist. This problem cannot

Re: [swift-evolution] Feature proposal: Range operator with step

On Mon, Apr 4, 2016 at 1:22 PM, Dave Abrahams wrote: > > on Sat Apr 02 2016, Xiaodi Wu wrote: > >> [snip] >> >> Not included: >> 1. I know Ranges are in flux, so I've held off on extending Range with >> a striding(by:) method in this proof-of-concept. > > They're not in

Re: [swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

This could potentially convert to Swift many library developers whose sanity depends on type guaranteed sequence sizes. I was just playing with Swift 2.2 along these lines, and got surprised how far I could get towards that ideal, see: http://codereview.stackexchange.com/q/124797/54297

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

> Le 31 mars 2016 à 23:41, Douglas Gregor via swift-evolution > a écrit : > : > https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md Wondering if this fit more in the lexer/in-house coding style bucket. For the supplied example of

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> My preference would be for there to be only one Self, and have it always be > the dynamic type of 'self'. Some people disagree, but I don't think it's all > that onerous to have to write ClassName.foo if that's really what you > specifically mean. +1. There's just no way we want to explain

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

> On 4 Apr 2016, at 18:18, Haravikk wrote: > >> >> On 4 Apr 2016, at 15:49, Jeremy Pereira >> wrote: >> >>> On 3 Apr 2016, at 17:20, Haravikk via swift-evolution >>> wrote: >>> >>> Although I use

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

> What is your evaluation of the proposal? +1. I like the rule of “don’t make me think”. If I write a piece of code that seems correct to me, why would the compiler “intentionally” stop me from accepting it? Just smooth out this rough edge and remove one scenario in which a compiler error

Re: [swift-evolution] My personal beef with leading-dot syntax

As others noted: * the ability to say .min, .max, .blackColor(), etc is extremely useful. Swift would be a lot worse off if only enum cases got their enum types inferred, and for any other static member of a type I would have type the fully qualified name * the leading dot disambiguates the

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

How would this work with OptionSetType? It also uses leading dot prefixes for initialisers, but implementations are usually structs. If I understand correctly, leading dot can be used in any case where the type can be inferred by the compiler. Changing the rules for enums seems strange to me.

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

> Is the lack of comments due to general disinterest in such a thing or did my > mail go amiss somehow? ;) I suspect it has something to do with the very similar thread I started about a week before you. :^)

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

> On 05 Apr 2016, at 08:19, T.J. Usiyan wrote: > > I missed it the first time around. > > I like this idea but worry that it will invite some difficult to follow > implementations. True. I think, the question is how flexible one wants enum to be. Right now, Swift

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

I missed it the first time around. I like this idea but worry that it will invite some difficult to follow implementations. I think that there would need to exist some restrictions on how methods could be broken up. One such restriction might be that these implementations could not be broken up

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

> On Mar 31, 2016, at 8:27 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0056 "Allow trailing closures in `guard` conditions" begins > now and runs through April 5, 2016. The proposal is available here: > >