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

> On Sep 29, 2016, at 3:05 PM, Russ Bishop wrote: > > >> On Sep 29, 2016, at 11:12 AM, Douglas Gregor > > wrote: >> >>> >>> On Sep 28, 2016, at 9:48 PM, Russ Bishop >> > wrote: >>>

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

Great explanation. Can you elaborate on your two reasons for the proposed Type? In particular, what do you mean by inheritable and non-inheritable members of T? Where do these come into play? How is the current T.Type deficient in this respect? Regarding (2), it is already possible to do

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

> On Sep 29, 2016, at 8:14 PM, Xiaodi Wu via swift-evolution > wrote: > > I'm confused by this explanation.Today, `type(of:)` is the new > `.dynamicType`. Is this proposal suggesting a silent change so that it now > returns the static type? If so, why (particularly

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

Sent from my iPhone > On Sep 29, 2016, at 7:45 PM, Jonathan Hull wrote: > > +1 to conditional conformances in general. >> >> What other designs were considered and rejected? It seems like some kind >> >> of escape hatch would be preferred if you happen to get into this >> >>

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

I'm confused by this explanation.Today, `type(of:)` is the new `.dynamicType`. Is this proposal suggesting a silent change so that it now returns the static type? If so, why (particularly when you explain that this is often *not* what you would want)? I'm also somewhat puzzled about the proposed

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

+1 to conditional conformances in general. > >> What other designs were considered and rejected? It seems like some kind > >> of escape hatch would be preferred if you happen to get into this > >> situation, though you make some really good points about the pitfalls. > > > > I don’t have a

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

>From Brent’s explanation, it sounds to me like “Type” and “StaticType” respectively would be more descriptive than “Subtype” and “Type” as proposed. Nevin On Thu, Sep 29, 2016 at 10:29 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Sep 29, 2016, at 3:24

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

> On Sep 29, 2016, at 3:24 PM, Russ Bishop via swift-evolution > wrote: > > Why would we not have type(of:) and subtype(of:)? Why would I want the > Subtype instead of the specific Type? Let's turn this around. Suppose you write: let obj: NSObject = …

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0143: Conditional Conformances

> • What is your evaluation of the proposal? This is a massively important and must-have feature. However, I'm dismayed by the size and complexity of the "detailed design" section. There are a *lot* of little nooks and crannies to this proposal. How certain are we that we've identified

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

> On Sep 28, 2016, at 3:18 AM, Adrian Zubarev via swift-evolution > wrote: > > func unsafeBitCast(_: T, to type: Type) -> U > func ==(t0: Subtype?, t1: Subtype?) -> Bool > func type(of: T) -> Subtype // SE-0096 > That last example, type(of:), is rather

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

> On Sep 29, 2016, at 11:12 AM, Douglas Gregor wrote: > >> >> On Sep 28, 2016, at 9:48 PM, Russ Bishop > > wrote: >> >> What other designs were considered and rejected? It seems like some kind of >> escape hatch would be

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

> On 29 Sep 2016, at 20:12, Douglas Gregor via swift-evolution > wrote: > > You get a compile error if there are two conformances of SomeWrapper to > Equatable; it doesn’t actually matter whether they are conditional, but > people are far more likely to expect to

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

> On Sep 29, 2016, at 10:16 AM, Joe Groff via swift-evolution > wrote: > > In the discussion around SE-0139 (bridging NSNumber and NSValue), many people > pointed out that it's common in ObjC to use NSNumbers holding enum constants > in Cocoa containers. Many ObjC

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

Well you kind of did say it should be removed. If we came up with a new design that produced an Int for sequences and an Index for collections, then you can't get an Int for collections (without wrapping the collection in AnySequence), which is basically the same thing as just removing

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

I think limiting to types that are both @objc and RawRepresentable is a nice compromise; that limits the type preservation needed to work around "slushiness" to NSString, NSNumber (already done), and NSError. I know your pitch doesn't cover this problem, but I would also note that C varargs

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

> On Sep 28, 2016, at 9:48 PM, Russ Bishop wrote: > > >> On Sep 26, 2016, at 5:18 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> Conditional conformances >> >> >>

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

In the discussion around SE-0139 (bridging NSNumber and NSValue), many people pointed out that it's common in ObjC to use NSNumbers holding enum constants in Cocoa containers. Many ObjC interfaces look something like this: /// A washing machine. @interface QXWashingMachine

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

IIUC, Jay wasn't arguing for renaming CharacterSet, but replacing it with Swift's existing Set mechanism. If/when generics get to the point that we can say 'extension Set {...}', I think the transition could simply be putting 'typealias CharacterSet = Set' somewhere in the framework (although

Re: [swift-evolution] Out of Scope Issues

> On 28 Sep 2016, at 08:23, Haravikk wrote: > > Also, is there a description somewhere of exactly what's in scope for the > next stage? The front-page for the swift-evolution github project seems to > still be focused on Swift 3.0, is there a permanent description somewhere? I > haven't been

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

2016-09-29 3:31 GMT+03:00 Colin Barrett via swift-evolution < swift-evolution@swift.org>: >- > >Type is the concrete type of T.self. A Type only ever has one >instance, T.self; even if T has a subtype U, Type is not a subtype >of Type. >- > >Subtype is the supertype of

[swift-evolution] [Pre-proposal] Enforcing Correct use of Array Indices

So the issue of Array index safety came up on the discussion for the .indexed() proposal. Now of course there's nothing wrong with arrays using integers as indices as such, but it does mean that indices can be manipulated outside of the array, which somewhat defeats the idea of the indexing

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

+1 to this idea. On the issue of discoverability, I wonder if .enumeratedByIndex() could be an alternative name for the new method? It's a bit verbose, but would cause it to come up as an option alongside .enumarated(), while being clear of the difference. > On 28 Sep 2016, at 18:55, Erica

Re: [swift-evolution] [Pitch] improve import sentence: allow import specific nested types

2 concerns 1) This introduces an ambiguity in qualified import syntax about whether identifiers after the dot are sub-modules or sub-structures. 2) Rarely do you want to import a substructure without also importing the parent. Often, APIs designed like there were built with this kind of