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

> On Sep 29, 2016, at 11:45 AM, Douglas Gregor via swift-evolution > wrote: >> > > > Personally, I consider the first one to be a fairly-low-risk extension to > SE-0139 that’s borderline bug-fix. We already know that those types have weak > numeric

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

> On Sep 28, 2016, at 3:15 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of “Conditional Conformances” begins now and runs through October > 7. The proposal is available here: > > >

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

> On Sep 29, 2016, at 7:29 PM, Brent Royal-Gordon > wrote: > >> 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

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

on Wed Sep 28 2016, Robert Widmann wrote: > +1. One of those things where you wonder why this wasn't the default > behavior. FWIW, it's because what Nevin did below is easy to write, but getting integer offsets isn't easy, at least not without introducing your own

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

on Wed Sep 28 2016, Erica Sadun wrote: > Indices have a specific, fixed meaning in Swift, which are used to create > valid collection > subscripts. This proposal introduces indexed() to produce a more semantically > relevant sequence by > pairing a collection's

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

on Fri Sep 30 2016, Matthew Johnson wrote: >> It’s a valid concern, and I’m sure it does come up in practice. Let’s create >> a small, self-contained example: >> >> protocol P { >> func f() >> } >> >> protocol Q: P { } >> >> struct X { let t: T} >> >> extension

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

On Fri, Sep 30, 2016 at 5:56 PM, Brent Royal-Gordon wrote: > > On Sep 29, 2016, at 9:21 PM, Xiaodi Wu wrote: > > > > Can you elaborate on your two reasons for the proposed Type? > > > > In particular, what do you mean by inheritable and

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

on Fri Sep 30 2016, Douglas Gregor wrote: >> On Sep 30, 2016, at 1:41 PM, Dave Abrahams wrote: >> >> >> on Fri Sep 30 2016, Douglas Gregor wrote: >> > On Sep 29, 2016, at 10:16 PM, Dave Abrahams via swift-evolution wrote:

Re: [swift-evolution] associated objects

On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution wrote: > Is it possible to have best of (these completely different) both worlds? Yes, of course it is. Your email spends a lot of words trying to form a false dichotomy. Swift can definitely

Re: [swift-evolution] associated objects

> On Sep 28, 2016, at 9:27 AM, Robert Widmann via swift-evolution > wrote: > > Have you got a significant use-case for this that absolutely can't be solved > by extensions or subclassing? > > This does have ABI impact but more concerning for me is the performance

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

> On Sep 30, 2016, at 1:41 PM, Dave Abrahams wrote: > > > on Fri Sep 30 2016, Douglas Gregor wrote: > >>> On Sep 29, 2016, at 10:16 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> Obviously I'm a huge +1 for this feature, but I

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

> On Sep 29, 2016, at 9:21 PM, Xiaodi Wu wrote: > > 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

Re: [swift-evolution] associated objects

> What it does is allow developers to extend the language to do things that it > doesn't support. Hitting boundaries... or so it seems... This is very interesting. In spite of its very modern approach, wether we like it or not, Swift is still a conventional Hard Coded Statical Programming

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

I replied on your gist directly, but you can also read my reply below. I though I made it crystal clear in my last post what the main problem is. Again: T.Type serves two jobs at once. It’s a concrete metatype of T. It’s an existential metatype of T where other metatypes where U is a subtype

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

2016-09-30 22:48 GMT+03:00 Xiaodi Wu via swift-evolution < swift-evolution@swift.org>: Sorry, my question at least has nothing to do with bikeshedding. I'm > confused about why the proposal feels it's necessary to have both Type and > Subtype. I don't understand Brent's two reasons and was hoping

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

on Fri Sep 30 2016, Douglas Gregor wrote: >> On Sep 29, 2016, at 10:16 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> Obviously I'm a huge +1 for this feature, but I have some concerns and >> questions about the particulars. > >> >> on Wed Sep 28 2016,

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

Sorry, my question at least has nothing to do with bikeshedding. I'm confused about why the proposal feels it's necessary to have both Type and Subtype. I don't understand Brent's two reasons and was hoping for some elaboration. I've tried to clarify my question in a gist:

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

About the proposed names: To be crystal clear we could use more descriptive names for our two types. Today T.Type is referred as *metatype* and serving two different purposes at once. It’s a concrete type; we call it Type or other suggested names looked like ExactType, StaticType etc. T.Type

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

> On Sep 30, 2016, at 6:25 AM, plx via swift-evolution > wrote: > > >> On Sep 28, 2016, at 5:53 PM, Douglas Gregor > > wrote: >> >> >>> On Sep 28, 2016, at 1:28 PM, plx via swift-evolution >>>

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

> On Sep 29, 2016, at 10:16 PM, Dave Abrahams via swift-evolution > wrote: > > > Obviously I'm a huge +1 for this feature, but I have some concerns and > questions about the particulars. > > on Wed Sep 28 2016, Joe Groff wrote: > >>

Re: [swift-evolution] class/struct inner member access scope classifier

Hi Jeremy and Nevin Sorry for the delay. quite busy. As described, the point of my message is that I would like to have the inner members of a class as default private, that is, not visible in the outer scope and to reveal members (entities) of the class to the outside world *explicitly* by

Re: [swift-evolution] associated objects

On Fri, 30 Sep 2016 at 15:41 Robert Widmann wrote: > "I want to do but the language doesn't support it” is the whole reason > for this list! I want to know what “” is in order to wrap my head > around your proposal better. I’m not here to invalidate your work with a

Re: [swift-evolution] associated objects

> On Sep 30, 2016, at 9:40 AM, Jay Abbott wrote: > > Robert, > > What it does is allow developers to extend the language to do things that it > doesn't support. Associated Objects is just a flexible way to allow > developers to do that, and that's how I used it in

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

> What is your evaluation of the proposal? Huge +1. Conditional conformances are at the very top of the list of frustrating limitations in Swift. Lifting that limitation can’t happen soon enough for me. I have some concern that the restriction on overlapping conformances could continue to

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

> On Sep 30, 2016, at 1:23 AM, Douglas Gregor wrote: > > >> On Sep 28, 2016, at 4:30 PM, Matthew Johnson > > wrote: >> Is the decision on "no-overlapping-conformances” something that’s seen-as set in stone

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

> On Sep 28, 2016, at 5:53 PM, Douglas Gregor wrote: > > >> On Sep 28, 2016, at 1:28 PM, plx via swift-evolution >> > wrote: >> >> It’s good to see this starting to happen! >> >> Is the decision on

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

on Thu Sep 29 2016, Haravikk wrote: > 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

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

on Wed Sep 28 2016, Erica Sadun wrote: > Chris: "Also, it is worth saying that any source breaking change still has to > have an > ultra-compelling reason to be worth considering. Despite having a framework > to > support some source breaking changes, we still

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

I’ll join the conversation tomorrow. Thanks to Brent for his huge contribution. :) Just a quick side note: Moving from T.Type and T.Protocol to Type and Subtype would also allow us to finally reuse and correctly nest our custom Type and Protocol types. struct A { struct Type {} } A.Type()

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

Hey Brent, Sorry for being a bit dense about this, but... > >NSObject >NSResponder: NSObject >NSView: NSResponder > > `Type` is a `Subtype`, but not a `Subtype`. > > Thus, this reads correctly: > >let aType: Subtype = NSView.self > > Whereas this does not: > >let aType:

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

> On Sep 29, 2016, at 6:46 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> • 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

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

> On Sep 28, 2016, at 4:30 PM, Matthew Johnson wrote: > >>> 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

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

Obviously I'm a huge +1 for this feature, but I have some concerns and questions about the particulars. on Wed Sep 28 2016, Joe Groff wrote: > Hello Swift community, > > The review of “Conditional Conformances” begins now and runs through October > 7. The proposal

Re: [swift-evolution] associated objects

> On Sep 28, 2016, at 9:27 AM, Robert Widmann via swift-evolution > wrote: > > To make this kind of pattern type safe you would, for example, need to keep > track metatype pointers too and use the dynamic cast machinery to check the > type on retrieval. Actually, a