Re: [swift-evolution] stored properties in extensions (was: associated objects)

Are stored properties in extensions already being discussed elsewhere? Is this one of those deferred-but-not-indexed-anywhere subjects? I wonder how stored properties could potentially be implemented, I can only think of two ways: 1. An extra pointer per instance (with resulting ABI

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

> On Oct 2, 2016, at 3:46 PM, Dave Abrahams via swift-evolution > wrote: > >> Do you mind providing some color on this design? It seems to me that >> the proposal's ObjectiveCBridgeable design was both more idiomatic > > How so? I mean merely that, when asked "How

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

on Sun Oct 02 2016, Brent Royal-Gordon wrote: >> On Oct 1, 2016, at 8:45 AM, Dave Abrahams via swift-evolution >> wrote: >> >>> I’m up for reviving the ObjectiveCBridgeable proposal :) >> >> Okay, but IMO the API of that protocol is

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

> On Oct 1, 2016, at 8:45 AM, Dave Abrahams via swift-evolution > wrote: > >> I’m up for reviving the ObjectiveCBridgeable proposal :) > > Okay, but IMO the API of that protocol is wrong. Any public interface > should look something like _CustomObjectiveCBridgeable

Re: [swift-evolution] NSString.contains(_:) returns false for empty string argument

on Mon Sep 05 2016, Ole Begemann wrote: > Six weeks ago there was a discussion [1] (and a subsequent fix [2]) > about the behavior of `String.hasPrefix(_:)` and > `String.hasSuffix(_:)` with empty string arguments. After the fix, > `str.hasPrefix("")` always returns

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

Interesting comment about worries that you'd be dispatched to the least good SS version . A different language with different constraints, but when LINQ to Objects implementers needed to provide optimized c# implementations for some operations they chose a runtime type check to dispatch to the

Re: [swift-evolution] [Pitch] Refactor Metatypes

Ups sorry. Found the mistake. Done. --  Adrian Zubarev Sent with Airmail Am 2. Oktober 2016 um 17:40:47, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: I don’t understand. I renamed Subtype with AnyType everywhere and mentioned it in Alternatives considered section.

Re: [swift-evolution] [Pitch] Refactor Metatypes

I’d say that subtype is correct there. As mentioned by some people here subtype feels like it has something to do with classes. Assume this: class Base { init() {...} } class A : Base {} let subtype: AnyType = subtype(of: Base.self, named: "A")! // One day when `.self` magic is gone

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] [swift-evolution-announce] [Review] SE-0143: Conditional Conformances

What is your evaluation of the proposal? +1 with concern about the least specialized implementation winning. I think that this could be tricky to explain or build an intuition around. Is the problem being addressed significant enough to warrant a change to Swift? Yes Does this proposal fit

Re: [swift-evolution] [Pitch] Refactor Metatypes

You can read the updated version of the proposal on a sub-branch: https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md --  Adrian Zubarev Sent with Airmail Am 2. Oktober 2016 um 11:47:50, Goffredo Marocchi (pana...@gmail.com)

Re: [swift-evolution] protocol-scoped methods

Honestly I am a bit concerned with protocols getting more and more code in them, default methods included. Protocols for me are best to abstract away, to decouple api behaviour from implementation... which also makes the system a lot easier to mock. Sent from my iPhone > On 2 Oct 2016, at

Re: [swift-evolution] [Pitch] Refactor Metatypes

Love it :)! Sent from my iPhone > On 2 Oct 2016, at 09:37, Adrian Zubarev via swift-evolution > wrote: > > That’s right. I was about to say something similar about the Of. > > Actually Type would be the correct name for the static/concrete metatype. > > We already

[swift-evolution] protocol-scoped methods

Howdy, Several months ago, there were a few well-received ideas on the list of adding functions which would have static-like dispatch directly scoped to protocols, instead of only to types conforming to those protocols. From a review of the mailing list, it looks like these ideas got lost

Re: [swift-evolution] [Pitch] Refactor Metatypes

That sounds very good to me, and AnyType aligns well with the proposed Any<...> syntax. — Pyry > Adrian Zubarev wrote: > > That’s right. I was about to say something similar about the Of. > > Actually Type would be the correct name for the static/concrete metatype. > > We already have this

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

On Wed, Sep 28, 2016 at 1:46 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > That's a bunch of complexity for no benefit. Why would you ever use this > as a collection? I think getting an element and an index simultaneously from, for instance,

Re: [swift-evolution] [Pitch] Refactor Metatypes

That’s right. I was about to say something similar about the Of. Actually Type would be the correct name for the static/concrete metatype. We already have this notation but not in a generic way T.Type If we add of only in our mind to Type, we’ll get “Type of a type T” which is shortly referred

Re: [swift-evolution] [Pitch] Refactor Metatypes

> Goffredo Marocchi wrote: > > I think the names should be bikeshedded more still. From your examples they > seem to make sense when I mentally add Of like TypeOf<> and SubTypeOf<>, but > since you are not commenting on why that is wrong or right or misleading, or > at least I have missed