Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

And of course it’s not like this is taking away functionality, just not adding it yet. So sure, +1, this is still forward progress. The fact it’s so easy to forget this other use of typealias doesn't really work in protocols right now is evidence enough for the proposal. Apologies for the

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

On a re-read I am -1; I like the `associatedtype` keyword but didn’t realize there was no plan to let `typealias` be used within a protocol to as a convenience (and to preserve intent, and to improve the development experience when still figuring out an interface design). I would prefer the

Re: [swift-evolution] Inquiry: Status of SR-122 ?

tion@swift.org> wrote: >> >>> On Jan 1, 2016, at 4:34 PM, plx via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> I was preparing a proposal-sketch relating to this earlier discussion: >>> http://article.gmane.or

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

I like this. > On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of "Replace `typealias` keyword with `associatedtype` for > associated type declarations” begins now and runs through Wednesday, January

Re: [swift-evolution] Proposal: CollectionType.cycle property for an infinite sequence

> On Dec 29, 2015, at 1:17 PM, Kevin Ballard via swift-evolution > <swift-evolution@swift.org> wrote: > > On Tue, Dec 29, 2015, at 08:14 AM, plx via swift-evolution wrote: >> Personally I’d say this should be a -1 for standard-library inclusion. >> >>

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Thanks for writing this up. Some quick points. Firstly, I think it is best if the `init(_ forwardeeReturnValue: Forwardee)`-style initializer be replaced by something with a distinctly-named argument, e.g. `init(forwardeeReturnValue value: Forwardee)`. For use with actual wrapper types the

Re: [swift-evolution] Proposal: CollectionType.cycle property for an infinite sequence

> On Dec 29, 2015, at 6:38 PM, Dave Abrahams <dabrah...@apple.com> wrote: > > >> On Dec 29, 2015, at 3:39 PM, plx via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Dec 29,

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 30, 2015, at 10:27 AM, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On Dec 30, 2015, at 10:06 AM, plx via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Thanks for writing this up. > > Thanks for re

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

I like this proposal overall and the proposed syntax in particular; I think it addresses a real issue in a straightforward, predictable way. As an aside — and FWIW — one thing I was at some point going to propose was a shorthand syntax for specifying trivial “argument-ordering-adjustment”

Re: [swift-evolution] [Review] Require self for accessing instance members

Quite quickly: I favor the proposal, but not for its stated reasons. In isolation it’s not a big deal to have implicit-self or to not have implicit-self. It does offer real conveniences, albeit ones that are IMHO rather small-and-petty. Given that, I think implicit self isn’t worth having if

Re: [swift-evolution] [Proposal] Property behaviors

I am excited by the general direction but I have some concerns about the scope of the design at this time; specifically, it seems like it would benefit a lot from having some flexible-and-efficient way for behaviors to “reach upward” back into their container from within their custom methods

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 10, 2016, at 12:59 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jun 10, 2016 at 12:30 PM, let var go > wrote: > I respect that anti-goal, but I think being over-rigid about limiting > developers'

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

This proposal should specify if the tuple is evaluated “eagerly” or as an “early-exit”. That is, if we write `if let (foo,bar,baz) = (_foo(), _bar(), _baz())`, and _bar() -> nil, will `_baz()` have been evaluated, or not? I’d use this feature either way, but the proposal should have a clear

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> > First, notice how your comment is related to the `where` clause but is > actually sitting on top of the loop itself. Second, one of these two tests > visits every element while the other doesn't, and it took me three reads > before I could see that because I literally couldn't find the

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

This reminds me of something: I *very* often wish the standard library had an analog to `NSIndexSet`. I bring it up b/c it would allow, here, for IMHO a rather nice way to write the *eager* variant of this `filterSplit` (or preferably imho, `partition`, if not for the *other* `partition` out

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution > wrote: > > >> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution >> wrote: >> >> I am 100% with Charlie on this. Expressiveness has to do with the >>

Re: [swift-evolution] Variadic generics discussion

I’ll keep this quick since I see upthread you have already revised the proposal. > On May 29, 2016, at 12:36 PM, Austin Zheng wrote: > >> …something like the above is definitely a "nice to have", but not having it >> will close off certain use cases. > > Oh, this is

Re: [swift-evolution] Variadic generics discussion

A few more comments inlined now that I’ve read it. > On May 30, 2016, at 7:44 AM, plx via swift-evolution > <swift-evolution@swift.org> wrote: > - if you have e.g. 2+ packs, can you enforce (T…) and (U…) have the same > arity? Seems the answer is yes iff there’s a `T.Foo..

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

Late response! As-specified, although I understand the *motivation* for this suggestion, I can’t support the specific proposal whatsoever. That said, I do think there’d be a lot of value in a way to add “convenience type predicates” (terrible name, please improve!) to declarations, so that

Re: [swift-evolution] [Pitch] Property reflection

I think this proposal should “simmer" until we know what property behaviors will look like (or find out they are never happening, etc.). The interaction with “property behaviors” seems likely to be quite subtle, even for something simple like `lazy`. For sake of argument, let’s say that a

Re: [swift-evolution] [Returned for revision] SE-0089: Renaming String.init(_: T)

I like the design strategy, but I’m having a hard time seeing the value of `ValuePreservingStringConvertible`; it’d be easier to evaluate the need for it with some concrete examples of types with `description` implementations that: - aren’t value-preserving - would cause problems if

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution > wrote: > > A `deriving` keyword, at the very least, is pretty explicitly *not* an > all-or-nothing situation. If you want to define equality/hashability for your > type manually, don't use `deriving`.

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 27, 2016, at 10:48 AM, Matthew Johnson <matt...@anandabits.com> wrote: > >> >> On May 27, 2016, at 10:37 AM, plx via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>&g

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 27, 2016, at 3:22 PM, Ricardo Parada via swift-evolution > wrote: > > Inline > > > On May 27, 2016, at 2:52 PM, Matthew Johnson > wrote: > >> >>> On May 27, 2016, at 12:48 PM, Ricardo

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 29, 2016, at 9:22 AM, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > >> On May 29, 2016, at 9:12 AM, Vladimir.S via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On 27.05.2016

Re: [swift-evolution] Variadic generics discussion

Thanks for getting the discussion started with such a thorough initial writeup. My overall concern is this: - on the one hand, I *very much* understand—and support—the idea of starting simple and adding functionality later - on the other hand, this is *already* a rather complicated proposal

Re: [swift-evolution] [Pitch] Property reflection

y > considered such that there are certain invariants that are still honored. > Like Laurent said earlier, bad things can happen if you use reflection to > subvert access control. > > I think reflection should be opt-in in most cases. Reflection opting-in > should be composabl

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

t can't be? > > > On Wed, Jun 22, 2016 at 9:13 AM, plx via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Prefacing the below with a “I am well-aware this proposal likely won’t make > it into Swift 3”: > > A feat

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

Prefacing the below with a “I am well-aware this proposal likely won’t make it into Swift 3”: A feature like this would be nice to use, but before I could get behind any proposal along these lines it I’d want to see it include an explicit strategy for disambiguation. EG: in your example, your

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

case this proposal should probably wait until at least August, as per suggestion. > On Jun 22, 2016, at 9:29 AM, Matthew Johnson <matt...@anandabits.com> wrote: > >> >> On Jun 22, 2016, at 9:11 AM, plx via swift-evolution >> <swift-evolution@swift.org <

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

+1; I *really* appreciate taking a proactive approach to eliminating future sources of bizarre “gotcha” moments! > On Jun 23, 2016, at 2:53 PM, Slava Pestov via swift-evolution > wrote: > > Consistent formal type for 'self' in class methods > > Proposal: SE- >

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

-1 for the reasons already brought up. I would also point out that half the biasing argument is extremely questionable: yes, for-in-where is “biased” in favor of “visit-if” and not "visit-unless”, but this form of “bias” is inevitable unless you start multiplying keywords (to have one for

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

I don’t see much value in moving them out of the angle brackets but preserving the position; consider: // status-quo: func anyCommonElements (lhs: T, _ rhs: U) -> Bool // as-per proposal: func anyCommonElements where T.Generator.Element: Equatable,

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Aside: `indices` being irregular can be a benefit in the context of auto-complete. > * What is your evaluation of the proposal? +1, very much. As a change from the current model, it’s an across-the-board improvement for me, at least. In a bigger-picture sense I think Swift would be

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 12, 2016, at 10:53 PM, Dmitri Gribenko <griboz...@gmail.com> wrote: > > On Tue, Apr 12, 2016 at 8:46 PM, plx via swift-evolution > <swift-evolution@swift.org> wrote: >> >> On Apr 12, 2016, at 6:11 PM, Haravikk <swift-evolut...@haravikk.me&g

Re: [swift-evolution] [Review] SE-0062: Referencing Objective-C key-paths

> What is your evaluation of the proposal? I like it and think it’s something Swift should definitely have. A quibble: I think there’d be value in also having: #key(ClassName.propertyName) …which is the same as `#keyPath`, but without support for *paths*. It’s functionally-redundant with

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Apr 1, 2016, at 7:37 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Protocol requirements with default (no-op) implementations already satisfy >> that design goal, no? > > Kind of. If I may steelman* optional members for a moment… I’d actually go a

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 5:34 AM, Haravikk <swift-evolut...@haravikk.me> wrote: > > >> On 13 Apr 2016, at 04:46, plx via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Invalidation is hard and I wouldn’t want anything held up to try a

Re: [swift-evolution] Mutability for Foundation types in Swift

On the one hand I like the idea (and particularly like the foundation types having meaningful `mutating` annotations, loosely speaking). On the other hand I have two questions: 1. will the NS types actually remain visible/usable (on supported platforms, perhaps requiring a specific import to

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

FWIW, you can avoid the multiple-preposition issue it differently: - isLessThanOrEqual(to:) => isNotGreaterThan(_:), isAtOrBelow(_:), etc. …neither of which I can claim to really like, but such possibilities exist. Offering in case there's a better phrasing along similar lines. > On Apr 20,

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

> On May 19, 2016, at 5:57 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue May 17 2016, Chris Lattner > wrote: > >> Hello Swift community, >> >> The review of "SE-0089: Renaming

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

Mixed; there are very good ideas here but combined in IMHO some questionably-strict ways. I understand that starting small and extending later is preferable, and I understand the Swift 3 situation. In favor of these: - allowing static methods to have “operator names” - deprecating operator

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

Do these return endIndex or nil on a not-found? Either can work with different tradeoffs; depends on what you care about...but the choice should be justified and the alternative explained. > On May 10, 2016, at 13:54, Nate Cook via swift-evolution > wrote: > > I've

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

Late, but +1 *overall*. For function signatures I am somewhat indifferent, honestly; I think having the option to move part of the `where` clause after the signature declaration is beneficial, but not hugely so. The reasoning here is simple: currently functions look like `func

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> * What is your evaluation of the proposal? +1 conceptually, some quibbles. I agree with a few others that `synchronously` and `asynchronously` aren’t ideal; `dispatchSynchronously` or `dispatchSync` (or `performSync` or `performSynchronously`) all seem more-appropriate. I understand

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

> On May 9, 2016, at 10:28 PM, Nate Cook via swift-evolution > wrote: > >> On May 9, 2016, at 9:48 PM, Joe Groff via swift-evolution >> > wrote: >> >>> >>> On May 9, 2016, at 6:23 PM, Brent Royal-Gordon

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

+1; this is great! I have nothing but good things to say about the proposal itself. I have two smaller questions, however; I apologize if they are off-topic. One is if there’s any ETA or similar for a glimpse at the “complete picture” of Swift’s revised numeric protocols; these floating-point

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 14, 2016, at 12:12 PM, Dave Abrahams via swift-evolution > wrote: >>> >>> No, you can't, at least not usefully. An Index that's at the end of one >>> collection is in the middle of another, or with a suitably-modified version >>> of the same collection.

Re: [swift-evolution] [Draft] Expanded min/max algorithms

I like the idea. It worries me a bit if the general recipe for such situations is to add dedicated-purpose methods like `_customIndexOfMinComparableElement` (etc.) to standard-library protocols; it *will* work, but is only going to work for the methods that get such treatment. If it were

Re: [swift-evolution] [Draft] Expanded min/max algorithms

I *quite* like `extrema`/`indicesOfExtrema` over minmax. > On Apr 17, 2016, at 10:03 AM, Patrick Pijnappel > wrote: > > I like the idea. A few notes on naming: > – minIndex is somewhat confusing to me (it sounds like it's getting the > minimum index, i.e.

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

If something is to happen I cast my vote for #2. I actually—and intentionally—use what that would call `numbered()` rather frequently; it’s not hard to write but not having to write it is nicer. Since the “indexed” version is also useful it’d be nice to have both, and with unambiguous names.

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 18, 2016, at 4:52 PM, Dave Abrahams via swift-evolution > wrote: > >> > > Again you're encoding “I'm at the end” in the index, which as we've > agreed does not work. If nothing else, it works—and seems natural—for linked lists. Sorry; if I’d remembered

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, plx wrote: > >>On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution >> wrote: >> >>on

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 4:26 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Apr 12 2016, Brent Royal-Gordon wrote: > >> In these cases, it would be better if the `successor(of:)` method was >> designed in a way that

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, plx > wrote: > > Seriously, just because Swift has Optionals and they're useful for > safety in some

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 15, 2016, at 9:00 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > This discussion is about a proposal for API to enumerate/count all possible > values of a type, particularly enums. The goal is to address potential issues > with an old proposal,

Re: [swift-evolution] Dropping Comparable requirement for indices

My own 2c is to drop the comparable requirement. I can elaborate if necessary, but wanted to at least cast my “+1” for removing the requirement. > On Jul 5, 2016, at 9:39 PM, Dave Abrahams via swift-evolution > wrote: > > > I've already raised the question here of

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

+1 except for the choice of names if I understand it correctly, but I want to make sure I understand it correctly. The scenario I want to to make sure I understand is what happens for a class-cluster type pattern like the following: // Module A: public class PublicBaseClass { func

Re: [swift-evolution] Dropping Comparable requirement for indices

> On Jul 6, 2016, at 7:33 PM, Xiaodi Wu wrote: > > I for one would be interested in your elaboration. Based on Dave's comments, > I'm pretty convinced that the Comparable requirement is best left in place. I am short on time (and will remain so for several more weeks) so

Re: [swift-evolution] [Manifesto] Ownership

1: Collection Composition As much as the high-level picture is focused on safety, I’d just like to request a strong focus on making sure the eventual ownership system addresses the common issues like avoiding copies when mutating through optionals, or when nesting collections, and so on.

Re: [swift-evolution] Sequence/Collection Enhancements

Some belated feedback. > On Feb 16, 2017, at 6:39 PM, Ben Cohen via swift-evolution > wrote: > Here is a list of commonly requested algorithms to operate on Sequence or > Collection: > > In-place transformations: > transform elements in a MutableCollection using a

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

+1 on most of it, with some minor quibbles. First quibble: between `Number` and `Arithmetic` I’d prefer `Arithmetic`; this is 50/50 aesthetics and concern about clarity vis-a-vis `(NS)Number`, `(NS)DecimalNumber`, and so on. Next quibble: `Magnitude` being defined as the “absolute value” of

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

> On Feb 23, 2017, at 11:31 AM, David Sweeris <daveswee...@mac.com> wrote: > > > On Feb 23, 2017, at 07:33, plx via swift-evolution <swift-evolution@swift.org > <mailto:swift-evolution@swift.org>> wrote: >> >> Next quibble: `Ma

Re: [swift-evolution] [Proposal draft] Conditional conformances

> On Sep 28, 2016, at 5:53 PM, Douglas Gregor <dgre...@apple.com> wrote: > > >> On Sep 28, 2016, at 1:28 PM, plx via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> It’s good to

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

> On Sep 28, 2016, at 4:47 PM, Kevin Ballard <ke...@sb.org> wrote: > > On Wed, Sep 28, 2016, at 02:27 PM, plx via swift-evolution wrote: >> +1 to have something *like* this, but a few questions. >> >> Is there a specific reason `IndexedSequence` isn’t `I

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

+1 to have something *like* this, but a few questions. Is there a specific reason `IndexedSequence` isn’t `IndexedCollection`, conforming to `Collection` (and once conditional conformances are available picking up `BidirectionalCollection` and `RandomAccessCollection` when possible?).

Re: [swift-evolution] [Proposal draft] Conditional conformances

It’s good to see this starting to happen! Is the decision on "no-overlapping-conformances” something that’s seen-as set in stone permanently, set in stone for the near future, or perhaps at least somewhat open to reconsideration at the present moment? > On Sep 26, 2016, at 7:18 PM, Douglas

Re: [swift-evolution] [Proposal draft] Conditional conformances

> On Sep 30, 2016, at 1:23 PM, Douglas Gregor wrote: >> >> This is purely anecdotal but I had a lot of utility code laying around that >> I’d marked with notes like `// TODO: revisit once conditional conformances >> are available`. >> >> When I was leaving those notes I

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

+ on the emoji-related parts, +1 in general spirit, +1 for the identifier cleanup, -103 for being needlessly overly-restrictive for operators; net -1 overall. Operator abuse is a social problem, and even if a technical fix is possible this isn’t that…and despite the messiness of the relevant

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

s disappear / appear invalid). > The syntax and underlying mental model is perhaps not as nice, but (assuming > the compiler is able to optimize away the nonescaping closure) we can achieve > some of the performance benefits. > >> On 2016-10-12, at 19:17, plx via swift-evoluti

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

tec...@gmail.com> wrote: > > >> On Oct 12, 2016, at 9:32 AM, plx via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> The issue addressed is real; I’m not sure this is the best approach. >> >> In

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 27, 2017, at 11:08 AM, John McCall <rjmcc...@apple.com> wrote: > >> On Feb 25, 2017, at 11:41 AM, plx via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> 1: Collection Composition >> >>