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

[Jay Abbott via swift-evolution]

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 compatability
implications) to hold a collection of the stored items.

2. A global lookup for any instance where stored properties have been set.

I'm not a language implementation expert, or familiar with the swift
implementation, so there may be other/better ways - I'd like to know if
there are?

If not, and option 2 was employed, a little foresight might enable the
mechanism to be overloaded in the future for other dynamic features too. A
bit flag (I'm hoping there's a spare bit in an existing flags field
somewhere?) could indicate whether any feature had caused the object to be
added to this lookup and deinit could check this bit and make sure the
object is removed, thus any stored properties are nilled. The lookup value
could be a struct with one member (extensionStoredProperties), and
additional members can be added in future for new features.

I get the impression from the associated objects discussion that perhaps
there are much better, more optimal, more ingenious, more unknown-by-me
ways of doing such things, so apologies if this whole idea is way-off the
mark :D

Jay

P.S. Note that stored properties in extensions could enable developers to
implement their own dynamic features in Swift.. so such desires could be
satisfied in the short term until they could be done properly in the
language.

On Sat, 1 Oct 2016 at 00:49 Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution@swift.org> 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 have both awesome dynamic features
> while still having performance, predictability and safety.
>
> > Would it be possible in Swift to have facilities to generate objects
> > dynamically at runtime? and, if desirable, how can such be implemented?
>
> Here’s an extant implementation that you can use today:
> https://github.com/Zewo/Reflection
>
> I’m sure it isn’t ideal, but it proves that it can be done.  When we have
> bandwidth to reevaluate this area from first principles, I’m sure we can
> make improvements on it.
>
> I will grant you that Smalltalk is a beautiful language in its simplicity,
> but for that simplicity it makes many tradeoffs that we’re not willing to
> make.  We are willing to make the internal implementation of Swift complex
> if that means that we get a beautiful model for programmers - one that
> preserves the virtues of safety-by-default, predictability, performance,
> and joy-to-develop-in.
>
> The meme of “Swift can never (or will never) support dynamic features” is
> tired, and also wildly inaccurate.
>
> -Chris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 do I create a new instance from some 
data?", Swift's preferred answer is "Write an initializer", and thus 
`init?(bridgedFromObjectiveC: ObjectiveCType)` is a more natural solution than 
`static func bridged(from: ObjectiveCType, by: 
Policy.Type) -> Self?`. Obviously this is a mere style concern and should be 
ignored if there are good reasons to use the other design, but it seems to me 
that it deserves at least a little bit of weight.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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 wrong.  Any public interface
>> should look something like _CustomObjectiveCBridgeable per
>>
> https://github.com/apple/swift/commit/87944ed2449ec7314ed8690b8894ce96ad339ebf#diff-9b6ea5442068d139aa4193a59b6e4b91
>
> 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?

> and permitted more behavior (particularly by allowing lazy collection
> bridging), whereas this design's only benefit seems to be that it
> abstracts away the specific "policy" (but that would prevent lazy
> bridging or other behavior differences between different
> policies). Why is this one better?

Because it results in far less code repetition and far more predictable
semantic relationships among the different bridging operations.

Yes, to agree with that design one has to buy into the idea that lazily
bridging from Objective-C is a net loss, and that any important cases
where it's a win can be dealt with well.  There are many strong reasons
to believe that's true, but we have some work ahead of us in order to
demonstrate it conclusively.

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> 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 per
> https://github.com/apple/swift/commit/87944ed2449ec7314ed8690b8894ce96ad339ebf#diff-9b6ea5442068d139aa4193a59b6e4b91

Do you mind providing some color on this design? It seems to me that the 
proposal's ObjectiveCBridgeable design was both more idiomatic and permitted 
more behavior (particularly by allowing lazy collection bridging), whereas this 
design's only benefit seems to be that it abstracts away the specific "policy" 
(but that would prevent lazy bridging or other behavior differences between 
different policies). Why is this one better?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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 `true`.
>
> This leads to inconsistent behavior with the `NSString.contains(_:)`
> method, which returns `false` for an empty string argument:
>
> let str = "Hello"
> str.contains("") // returns false
>
> If `contains` were part of the stdlib like `hasPrefix` and `hasSuffix`
> are, I would consider this a bug. But `contains` comes from Foundation
> and I'm not sure how that changes things. Would it make sense to add a
> variant of `contains(_:)` to the stdlib and fix the behavior there?

It might be worth doing something for Swift 3.1

>
> I'm assuming it's too late for Swift 3 and it will be fixed with the
> String remodeling in Swift 4 anyway, 

That's my plan.

> but I just noticed this and I thought I'd ask.
>
> Ole
>
> [1]: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024630.html
> [2]: https://bugs.swift.org/browse/SR-2131
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Callionica (Swift) via swift-evolution]

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
optimized version. For example, while API is exposed as IEnumerable
there are method implementations that check for ICollection at runtime
in order to hit more efficient implementations. So static dispatch is good,
but win for collections often big enough to overcome a hit from dynamic
dispatch.

On Sunday, October 2, 2016, plx via swift-evolution <
swift-evolution@swift.org> wrote:

>
> 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 was expecting to need overlapping
> conformances often, but I reviewed them *before* replying and I actually
> haven’t found an example where having overlapping conformances is both (1)
> a significant win and also (2) a win in a way that’d be of broad, general
> interest.
>
> - 80% have no real need for overlapping conditional conformances
> - 15% might have “elegance gains” but nothing practically-significant
> - 5% would *probably* see real gains but are likely not of broad interest
>
> …which wasn’t what I was expecting, but leaves me a lot more comfortable
> without overlapping conformances for now than I was in the abstract.
>
>
> Very interesting, thanks for doing this review!
>
>
> I've taken the time to provide a bit more color on the 80/15/5 breakdown
> because I don't see much discussion for this proposal in terms of concrete
> situations...just theoretical concerns and theoretical possibilities. I
> don't have any completed code either, but I have notes and to-do lists for
> things I was planning to do, and I think seeing even some semi-concrete
> scenarios might be helpful here.
>
> The "80%" are generally analogous to the `SomeWrapper` in the writeup; as
> a concrete example, I was waiting on the availability of conditional
> conformances to resume work on an emulation of structural unions, e.g.
> something like:
>
>   enum Sum2 {
> case a(A)
> case b(B)
>   }
>
> ...(and analogously for 3, 4, as-necessary).
>
> There's a very obvious way to write `extension Sum2 : Equatable where
> A:Equatable, B:Equatable {}`...and at the time I set this aside, I was
> expecting to also want to come back and have additional conformances for
> things like `...where A:Equatable, B:AnyObject` (using `===` for comparing
> `B`) and so on for other combinations.
>
> Upon revisiting such things in light of the proposal, I now think
> differently: for this case it seems like a better long-term approach
> anyways to stick to a single conformance and work with it like this:
>
>   extension Sum2:Equatable where A:Equatable, B:Equatable {
> // details elided
>   }
>
>   /// Adaptor using `ObjectIdentifier` to implement `==`.
>   struct ObjectWrapper : Equatable, Hashable {
> let wrapped: Wrapped
>   }
>
> ...as upon reflection I really would prefer dealing with the hassle of
> working with `Sum2` in situations where -- in theory --
> `Sum2` could do -- to the hassle of writing out 4+ conformances for
> `Sum2` (and so on...even with nice code-gen tools that's going to be a lot
> of bloat!).
>
> What changed my mind was tracing through the implications of conditional
> conformances for the use-site ergonomics of adaptors like `ObjectWrapper`
> above; what I mean is, suppose I have a protocol like this:
>
>   protocol WidgetFactory {
> associatedtype Widget
> associatedtype Material
>
> func produceWidget(using material: Material) -> Widget
>   }
>
> ...then it's rather easy to simply write this type of boilerplate:
>
>   extension ObjectWrapper: WidgetFactory where Wrapped: WidgetFactory {
> typealias Widget = Wrapper.Widget
> typealias Material = Wrapper.Material
>
> func produceWidget(using material: Material) -> Widget {
>   return base.produceWidget(using: material)
> }
>   }
>
> ...which thus means I have the tools I need to make my use of wrappers
> like the `ObjectWrapper` largely transparent at the use sites I care about;
> e.g. I can write a single conditional conformance like this:
>
>   extension Sum2: WidgetFactory
> where
> A:WidgetFactory, B:WidgetFactory,
> A.Material == B.Material,
> A.Widget == B.Widget {
>
> typealias Widget = A.Widget
> typealias Material = A.Material
>
> func produceWidget(using material: Material) throws -> Widget {
>   switch self {
> case let .a(aa): return aa.produceWidget(using: material)
> case let .b(bb): return bb.produceWidget(using: material)
> 

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

[Adrian Zubarev via swift-evolution]

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.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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
let subtype: AnyType = subtype(of: Base, named: "A")!
 
let a: Base = subtype.init()
 
print(type(of: a)) // => A
It’s clear that we’re working with classes here. type(of:named:) seems odd to 
me and doesn’t fit here at all.

Any more feedback?

Waiting for Brent to reply. I can’t remember what Subprotocol was for. 
That’s the reason why it looks like this for the moment. ;)

I don’t understand. I renamed Subtype with AnyType everywhere and mentioned it 
in Alternatives considered section.

I’d like to wait for more feedback, we’re not in rush now.



-- 
Adrian Zubarev
Sent with Airmail

Am 2. Oktober 2016 um 16:46:18, Anton Zhilin (antonyzhi...@gmail.com) schrieb:

I’m happy that everyone seems to agree on the new naming, and I also like that  
type function is back.

Some fixes:

In Future directions, replace  
subtype with  
type
In Future directions, remove overstruck last item
In Alternatives considered, replace the naming and add old naming to 
alternative options
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[plx via swift-evolution]

> 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 was expecting to need overlapping 
>> conformances often, but I reviewed them *before* replying and I actually 
>> haven’t found an example where having overlapping conformances is both (1) a 
>> significant win and also (2) a win in a way that’d be of broad, general 
>> interest.
>> 
>> - 80% have no real need for overlapping conditional conformances
>> - 15% might have “elegance gains” but nothing practically-significant
>> - 5% would *probably* see real gains but are likely not of broad interest
>> 
>> …which wasn’t what I was expecting, but leaves me a lot more comfortable 
>> without overlapping conformances for now than I was in the abstract.
> 
> Very interesting, thanks for doing this review!

I've taken the time to provide a bit more color on the 80/15/5 breakdown 
because I don't see much discussion for this proposal in terms of concrete 
situations...just theoretical concerns and theoretical possibilities. I don't 
have any completed code either, but I have notes and to-do lists for things I 
was planning to do, and I think seeing even some semi-concrete scenarios might 
be helpful here.

The "80%" are generally analogous to the `SomeWrapper` in the writeup; as a 
concrete example, I was waiting on the availability of conditional conformances 
to resume work on an emulation of structural unions, e.g. something like:

  enum Sum2 {
case a(A)
case b(B)
  }
  
...(and analogously for 3, 4, as-necessary). 

There's a very obvious way to write `extension Sum2 : Equatable where 
A:Equatable, B:Equatable {}`...and at the time I set this aside, I was 
expecting to also want to come back and have additional conformances for things 
like `...where A:Equatable, B:AnyObject` (using `===` for comparing `B`) and so 
on for other combinations.

Upon revisiting such things in light of the proposal, I now think differently: 
for this case it seems like a better long-term approach anyways to stick to a 
single conformance and work with it like this:

  extension Sum2:Equatable where A:Equatable, B:Equatable {
// details elided
  }
  
  /// Adaptor using `ObjectIdentifier` to implement `==`.
  struct ObjectWrapper : Equatable, Hashable {
let wrapped: Wrapped
  }
  
...as upon reflection I really would prefer dealing with the hassle of working 
with `Sum2` in situations where -- in theory -- `Sum2` 
could do -- to the hassle of writing out 4+ conformances for `Sum2` (and so 
on...even with nice code-gen tools that's going to be a lot of bloat!). 

What changed my mind was tracing through the implications of conditional 
conformances for the use-site ergonomics of adaptors like `ObjectWrapper` 
above; what I mean is, suppose I have a protocol like this:

  protocol WidgetFactory {
associatedtype Widget
associatedtype Material

func produceWidget(using material: Material) -> Widget
  }

...then it's rather easy to simply write this type of boilerplate:

  extension ObjectWrapper: WidgetFactory where Wrapped: WidgetFactory {
typealias Widget = Wrapper.Widget
typealias Material = Wrapper.Material

func produceWidget(using material: Material) -> Widget {
  return base.produceWidget(using: material)
}
  }
  
...which thus means I have the tools I need to make my use of wrappers like the 
`ObjectWrapper` largely transparent at the use sites I care about; e.g. I can 
write a single conditional conformance like this:

  extension Sum2: WidgetFactory 
where 
A:WidgetFactory, B:WidgetFactory,
A.Material == B.Material,
A.Widget == B.Widget {

typealias Widget = A.Widget
typealias Material = A.Material

func produceWidget(using material: Material) throws -> Widget {
  switch self {
case let .a(aa): return aa.produceWidget(using: material)
case let .b(bb): return bb.produceWidget(using: material)
  }
}

  }
  
...and it will apply even in situations where circumstances left me using 
`ObjectWrapper` (or similar) on any of the type parameters to `Sum2` (e.g. if I 
also needed an `Equatable` conformance for whatever reason).

At least for now--when I'm still just revisiting plans and thinking about it in 
light of the proposal--I really would prefer having a simpler language and 
writing this type of boilerplate, than having a more-complex language and 
writing the *other* type of boilerplate (e.g. the 4+ `Equatable` conformances 
here, and so on for other situations).

Note that I'm not claiming the above is the only use for overlapping 
conditional conformances -- not at all! -- just that situations like the above 
comprise about 80% of the things I was intending to do with conditional 

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

[T.J. Usiyan via swift-evolution]

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 well with the feel and direction of Swift?
Yes
If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
It holds up in general against other systems.
How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
Quick reading and I have followed the discussion closely.

On Sat, Oct 1, 2016 at 4:39 AM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> Comments on: The review of “Conditional Conformances” begins now and runs
> through October 7. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposa
> ls/0143-conditional-conformances.md
>
>
>- What is your evaluation of the proposal?
>
> Great
>
>- Is the problem being addressed significant enough to warrant
>a change to Swift?
>
> Yes
>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes
>
>- If you have used other languages or libraries with a
>similar feature, how do you feel that this proposal compares to those?
>
> No
>
>- How much effort did you put into your review? A glance, a
>quick reading, or an in-depth study?
>
> Having written my own collection library and also extended the existing
> one I have hit this limitation and would therefore welcome this addition.
>
> On Thursday, 29 September 2016, Joe Groff  wrote:
>
>> Hello Swift community,
>>
>> The review of “Conditional Conformances” begins now and runs through
>> October 7. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/0143-conditional-conformances.md
>>
>> Reviews are an important part of the Swift evolution process. All
>> reviews should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> or, if you would like to keep your feedback private, directly to
>> the review manager. When replying, please try to keep the proposal link
>> at the top of the message:
>>
>> Proposal link:
>>
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/0143-conditional-conformances.md
>>
>> Reply text
>>
>> Other replies
>>
>> What goes into a review?
>>
>> The goal of the review process is to improve the proposal under
>> review through constructive criticism and, eventually, determine the
>> direction of Swift. When writing your review, here are some questions you
>> might want to answer in your review:
>>
>>- What is your evaluation of the proposal?
>>- Is the problem being addressed significant enough to warrant
>>a change to Swift?
>>- Does this proposal fit well with the feel and direction of Swift?
>>- If you have used other languages or libraries with a
>>similar feature, how do you feel that this proposal compares to those?
>>- How much effort did you put into your review? A glance, a
>>quick reading, or an in-depth study?
>>
>> More information about the Swift evolution process is available at
>>
>> https://github.com/apple/swift-evolution/blob/master/process.md
>>
>> Thank you,
>>
>> -Joe
>>
>> Review Manager
>>
>
>
> --
> -- Howard.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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) schrieb:

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 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 as a “metatype of T”. (Array - Array of Element type)
Since Subtype in reality is some *existential metatype* and the whole talk 
about existential types now tend to have the Any prefix, lets follow that trend 
here too.

Type - (static/concrete/exact) metatype.
AnyType - existential metatype.
It might be even easier to memorise this name than Subtype.

The example from the proposal rewritten:

// Types:
protocol Foo {}
protocol Boo : Foo {}
class A : Foo {}
class B : A, Boo {}
struct S : Foo {}

// Metatypes:
let a1: Type = A.self   //=> Okay
let p1: Type = Foo.self   //=> Okay
let p2: Type = C.self //=> Error -- `C` is not the same as `Foo`

let any_1: AnyType = A.self   //=> Okay
let any_2: AnyType = Foo.self //=> Okay

let a_1: AnyType = A.self   //=> Okay
let p_1: AnyType = A.self //=> Okay
let p_2: AnyType = Foo.self   //=> Error -- `Type` is not a subtype 
of `AnyType`

// Generic functions:
func dynamic(type: AnyType, `is` _: Type) -> Bool {
  return type is AnyType
}

func dynamic(type: AnyType, `as` _: Type) -> AnyType? {
  return type as? AnyType
}

let s1: Type = S.self

dynamic(type: s1, is: Foo.self)//=> true
dynamic(type: s1, as: Foo.self)//=> an `Optional`
The type(of:) function could now stay, because now we’d only need to change the 
return type.

func type(of instance: T) -> AnyType
Isn’t this a good compromise?



-- 
Adrian Zubarev
Sent with Airmail

Am 2. Oktober 2016 um 09:01:45, Pyry Jahkola via swift-evolution 
(swift-evolution@swift.org) schrieb:

OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
while we still pronounce them that way. I don't think prepositions belong in 
the name of types but in exceptional cases, and this doesn't sound exceptional 
enough to me.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] protocol-scoped methods

[Goffredo Marocchi via swift-evolution]

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 10:42, Benjamin Spratling via swift-evolution 
>  wrote:
> 
> 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 amongst 
> some others, and the goal at the time was “cut & fix”, not “add”.
> I’m concerned these may require ABI changes, and I’ve noticed their absence 
> negatively affects my code designs, so I’m bring them back up.
> 
> The first, and maybe most obvious is protocol-scoped functions.
> 
> Right now, static functions require a conforming type, even when default 
> implementations exist.
> 
> protocol Usable {
>static func use()
> }
> 
> extension Usable {
>static func use() { }
> }
> 
> struct User : Usable {
> }
> 
> User.use()//compiles
> type(of:User()).use()//compiles
> 
> struct AnotherUser : Usable {
>static func use() { }
> }
> 
> AnotherUser.use()//compiles & calls  AnotherUser’s implementation instead 
> of protocol default
> 
> While that is useful, and I’m not suggesting removing it, there is room for 
> another kind of static-like method, one which does not require knowledge of 
> an instance of a conforming type, nor of a conforming type.  A 
> protocol-scoped method
> 
> protocol Usable {
> }
> 
> extension Usable {
>protocol func use() { }
> }
> 
> Usable.use()//if accepted, this would compile end execute.
> 
> Right now, “static” methods must have a supported type.
> 
> Without this feature:
> 1. many methods become global, which feels very inappropriate in Swift
> 2. To get nice inits for “Struct clusters”, they become become enums, which 
> does not leave them open for extension, the opposite of the intention of 
> protocols.
> 
> With this feature:
> Common pre-validation or -pre-instantiation logic would be available to code 
> which works directly with protocols , instead of only code in another module 
> which knows about concrete types of it.
> The function is not included in the original protocol definition, because it 
> is not something which must be implemented by the conforming type.
> 
> A derivative concept is protocol-scoped stored vars/lets.  Like static vars & 
> let, protocol-scoped vars & lets have static storage, but are name spaced by 
> the protocol, instead of getting dumped into the global name space.
> 
> As an example, I have a protocol which creates URLRequests for data 
> serialized as JSON.  I’d like to have a protocol-scoped “jsonMimeType” var 
> for insertion in my algorithm, but that is not currently allowed, at least 
> not using a good name-space.  In fact, it’s not even allowed as a static 
> var/let right now, at least with a default implementation.  And since this is 
> something that shouldn’t be overridden, it doesn’t make sense in a static, 
> who’s default implementation could be replaced by a conforming type’s 
> implementation.
> 
> Protocol Nested Types.
> I understand there’s a lot of work to do to support nested generics, but 
> surely nested non-generics are pretty straight forward?
> 
> For instance, I have a protocol which requires instances to implement a 
> method which returns a case of an enum which is peculiar to that protocol.  I 
> may very well wish to make the enum a nested type of the protocol.  This 
> feels like a natural extension of the language.
> 
> Two of the emails mentioned the desire for “existential protocols”, but in an 
> hour of searching, I did not find an “existential protocol manifesto”, so I 
> don’t know.
> 
> Questions:
> 1. Have I missed something, and these features are already supported in Swift?
> 2. Would these features benefit your use of Swift?
> 3. Would these features affect the ABI?
> 4. Are these features part of a larger initiative already considered? (links 
> please)
> 
> -Ben Spratling
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

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 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 as a “metatype of T”. (Array - Array of Element 
> type)
> Since Subtype in reality is some *existential metatype* and the whole talk 
> about existential types now tend to have the Any prefix, lets follow that 
> trend here too.
> 
> Type - (static/concrete/exact) metatype.
> AnyType - existential metatype.
> It might be even easier to memorise this name than Subtype.
> 
> The example from the proposal rewritten:
> 
> // Types:
> protocol Foo {}
> protocol Boo : Foo {}
> class A : Foo {}
> class B : A, Boo {}
> struct S : Foo {}
> 
> // Metatypes:
> let a1: Type = A.self   //=> Okay
> let p1: Type = Foo.self   //=> Okay
> let p2: Type = C.self //=> Error -- `C` is not the same as `Foo`
> 
> let any_1: AnyType = A.self   //=> Okay
> let any_2: AnyType = Foo.self //=> Okay
> 
> let a_1: AnyType = A.self   //=> Okay
> let p_1: AnyType = A.self //=> Okay
> let p_2: AnyType = Foo.self   //=> Error -- `Type` is not a subtype 
> of `AnyType`
> 
> // Generic functions:
> func dynamic(type: AnyType, `is` _: Type) -> Bool {
>   return type is AnyType
> }
> 
> func dynamic(type: AnyType, `as` _: Type) -> AnyType? {
>   return type as? AnyType
> }
> 
> let s1: Type = S.self
> 
> dynamic(type: s1, is: Foo.self)//=> true
> dynamic(type: s1, as: Foo.self)//=> an `Optional`
> The type(of:) function could now stay, because now we’d only need to change 
> the return type.
> 
> func type(of instance: T) -> AnyType
> Isn’t this a good compromise?
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 2. Oktober 2016 um 09:01:45, Pyry Jahkola via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
>> while we still pronounce them that way. I don't think prepositions belong in 
>> the name of types but in exceptional cases, and this doesn't sound 
>> exceptional enough to me.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] protocol-scoped methods

[Benjamin Spratling via swift-evolution]

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 amongst 
some others, and the goal at the time was “cut & fix”, not “add”.
I’m concerned these may require ABI changes, and I’ve noticed their absence 
negatively affects my code designs, so I’m bring them back up.

The first, and maybe most obvious is protocol-scoped functions.

Right now, static functions require a conforming type, even when default 
implementations exist.

protocol Usable {
static func use()
}

extension Usable {
static func use() { }
}

struct User : Usable {
}

User.use()  //compiles
type(of:User()).use()   //compiles

struct AnotherUser : Usable {
static func use() { }
}

AnotherUser.use()   //compiles & calls  AnotherUser’s implementation 
instead of protocol default

While that is useful, and I’m not suggesting removing it, there is room for 
another kind of static-like method, one which does not require knowledge of an 
instance of a conforming type, nor of a conforming type.  A protocol-scoped 
method

protocol Usable {
}

extension Usable {
protocol func use() { }
}

Usable.use()//if accepted, this would compile end execute.

Right now, “static” methods must have a supported type.

Without this feature:
1. many methods become global, which feels very inappropriate in Swift
2. To get nice inits for “Struct clusters”, they become become enums, which 
does not leave them open for extension, the opposite of the intention of 
protocols.

With this feature:
Common pre-validation or -pre-instantiation logic would be available to code 
which works directly with protocols , instead of only code in another module 
which knows about concrete types of it.
The function is not included in the original protocol definition, because it is 
not something which must be implemented by the conforming type.

A derivative concept is protocol-scoped stored vars/lets.  Like static vars & 
let, protocol-scoped vars & lets have static storage, but are name spaced by 
the protocol, instead of getting dumped into the global name space.

As an example, I have a protocol which creates URLRequests for data serialized 
as JSON.  I’d like to have a protocol-scoped “jsonMimeType” var for insertion 
in my algorithm, but that is not currently allowed, at least not using a good 
name-space.  In fact, it’s not even allowed as a static var/let right now, at 
least with a default implementation.  And since this is something that 
shouldn’t be overridden, it doesn’t make sense in a static, who’s default 
implementation could be replaced by a conforming type’s implementation.

Protocol Nested Types.
I understand there’s a lot of work to do to support nested generics, but surely 
nested non-generics are pretty straight forward?

For instance, I have a protocol which requires instances to implement a method 
which returns a case of an enum which is peculiar to that protocol.  I may very 
well wish to make the enum a nested type of the protocol.  This feels like a 
natural extension of the language.

Two of the emails mentioned the desire for “existential protocols”, but in an 
hour of searching, I did not find an “existential protocol manifesto”, so I 
don’t know.

Questions:
1. Have I missed something, and these features are already supported in Swift?
2. Would these features benefit your use of Swift?
3. Would these features affect the ABI?
4. Are these features part of a larger initiative already considered? (links 
please)

-Ben Spratling

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

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 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 as a “metatype of T”. (Array - Array of Element 
> type)
> Since Subtype in reality is some *existential metatype* and the whole talk 
> about existential types now tend to have the Any prefix, lets follow that 
> trend here too.
> 
> Type - (static/concrete/exact) metatype.
> AnyType - existential metatype.
> It might be even easier to memorise this name than Subtype.
> 
> The example from the proposal rewritten:
> 
> // Types:
> protocol Foo {}
> protocol Boo : Foo {}
> class A : Foo {}
> class B : A, Boo {}
> struct S : Foo {}
> 
> // Metatypes:
> let a1: Type = A.self   //=> Okay
> let p1: Type = Foo.self   //=> Okay
> let p2: Type = C.self //=> Error -- `C` is not the same as `Foo`
> 
> let any_1: AnyType = A.self   //=> Okay
> let any_2: AnyType = Foo.self //=> Okay
> 
> let a_1: AnyType = A.self   //=> Okay
> let p_1: AnyType = A.self //=> Okay
> let p_2: AnyType = Foo.self   //=> Error -- `Type` is not a subtype 
> of `AnyType`
> 
> // Generic functions:
> func dynamic(type: AnyType, `is` _: Type) -> Bool {
>   return type is AnyType
> }
> 
> func dynamic(type: AnyType, `as` _: Type) -> AnyType? {
>   return type as? AnyType
> }
> 
> let s1: Type = S.self
> 
> dynamic(type: s1, is: Foo.self)//=> true
> dynamic(type: s1, as: Foo.self)//=> an `Optional`
> The type(of:) function could now stay, because now we’d only need to change 
> the return type.
> 
> func type(of instance: T) -> AnyType
> Isn’t this a good compromise?
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 2. Oktober 2016 um 09:01:45, Pyry Jahkola via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
>> while we still pronounce them that way. I don't think prepositions belong in 
>> the name of types but in exceptional cases, and this doesn't sound 
>> exceptional enough to me.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

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,
collection.indexed().sorted(by:) or collection.indexed().first(where:)
could be quite useful.

Jacob


> The whole point is to be used in a for loop. If it was a collection then
> you'd need to have an index for that collection, so now you have an index
> that lets you get the index for another collection, which is pretty useless
> because you could just be using that underlying index to begin with.
>
> -Kevin
>
> On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution wrote:
> > +1 for `indexed()`, but I’m not sure about `IndexedSequence`. Why not
> `IndexedCollection`, which could also conform to Collection? With
> conditional conformances to BidirectionalCollection and
> RandomAccessCollection. This wouldn’t penalise the performance with respect
> to a simple `IndexedSequence`, would it?
> >
> > > Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3
> f2
> > >
> > > Introducingindexed()collections
> > > Proposal: TBD
> > > Author:Erica Sadun(https://github.com/erica),Nate Cook(
> https://github.com/natecook1000),Jacob Bandes-Storch(https://github.
> com/jtbandes),Kevin Ballard(https://github.com/kballard)
> > > Status: TBD
> > > Review manager: TBD
> > >
> > > Introduction
> > >
> > > This proposal introducesindexed()to the standard library, a method on
> collections that returns an (index, element) tuple sequence.
> > >
> > >
> > > Swift-evolution thread:TBD(https://gist.github.com/erica/tbd)
> > >
> > > Motivation
> > >
> > > The standard library'senumerated()method returns a sequence of pairs
> enumerating a sequence. The pair's first member is a monotonically
> incrementing integer starting at zero, and the second member is the
> corresponding element of the sequence. When working with arrays, the
> integer is coincidentally the same type and value as anArrayindex but the
> enumerated value is not generated with index-specific semantics. This may
> lead to confusion when developers attempt to subscript a non-array
> collection with enumerated integers. It can introduce serious bugs when
> developers useenumerated()-based integer subscripting with non-zero-based
> array slices.
> > >
> > >
> > > Indices have a specific, fixed meaning in Swift, which are used to
> create valid collection subscripts. This proposal introducesindexed()to
> produce a more semantically relevant sequence by pairing a
> collection'sindiceswith its members. While it is trivial to create a
> solution in Swift, the most common developer approach shown here calculates
> indexes twice:
> > >
> > > extension Collection {   /// Returns a sequence of pairs (*idx*, *x*),
> where *idx* represents a   /// consecutive collection index, and *x*
> represents an element of   /// the sequence.   func indexed()
> ->Zip2Sequence{ return zip(indices, self)   } }
> > >
> > > Incrementing an index in some collections can be unnecessarily costly.
> In a lazy filtered collection, an index increment is potentially O(N). We
> feel this is better addressed introducing a new function into the Standard
> Library to provide a more efficient design that avoids the attractive
> nuisance of the "obvious" solution.
> > >
> > > Detailed Design
> > >
> > > Our vision ofindexed()bypasses duplicated index generation with their
> potentially high computation costs. We'd create an iterator that calculates
> each index once and then applies that index to subscript the collection.
> Implementation would take place throughIndexedSequence, similar
> toEnumeratedSequence.
> > >
> > > Impact on Existing Code
> > >
> > > This proposal is purely additive and has no impact on existing code.
> > >
> > > Alternatives Considered
> > > Not yet
> > >
> > >
> > >
> > >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 as a “metatype of T”. (Array - Array of Element type)
Since Subtype in reality is some *existential metatype* and the whole talk 
about existential types now tend to have the Any prefix, lets follow that trend 
here too.

Type - (static/concrete/exact) metatype.
AnyType - existential metatype.
It might be even easier to memorise this name than Subtype.

The example from the proposal rewritten:

// Types:
protocol Foo {}
protocol Boo : Foo {}
class A : Foo {}
class B : A, Boo {}
struct S : Foo {}

// Metatypes:
let a1: Type = A.self   //=> Okay
let p1: Type = Foo.self   //=> Okay
let p2: Type = C.self //=> Error -- `C` is not the same as `Foo`

let any_1: AnyType = A.self   //=> Okay
let any_2: AnyType = Foo.self //=> Okay

let a_1: AnyType = A.self   //=> Okay
let p_1: AnyType = A.self //=> Okay
let p_2: AnyType = Foo.self   //=> Error -- `Type` is not a subtype 
of `AnyType`

// Generic functions:
func dynamic(type: AnyType, `is` _: Type) -> Bool {
  return type is AnyType
}

func dynamic(type: AnyType, `as` _: Type) -> AnyType? {
  return type as? AnyType
}

let s1: Type = S.self

dynamic(type: s1, is: Foo.self)//=> true
dynamic(type: s1, as: Foo.self)//=> an `Optional`
The type(of:) function could now stay, because now we’d only need to change the 
return type.

func type(of instance: T) -> AnyType
Isn’t this a good compromise?



-- 
Adrian Zubarev
Sent with Airmail

Am 2. Oktober 2016 um 09:01:45, Pyry Jahkola via swift-evolution 
(swift-evolution@swift.org) schrieb:

OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
while we still pronounce them that way. I don't think prepositions belong in 
the name of types but in exceptional cases, and this doesn't sound exceptional 
enough to me.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pyry Jahkola via swift-evolution]

> 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 your reply on that, I am still a bit at loss. Maybe we 
> need other words altogether?

OTOH, we don't have ArrayOf or DictionaryOfKeyAndValue, 
while we still pronounce them that way. I don't think prepositions belong in 
the name of types but in exceptional cases, and this doesn't sound exceptional 
enough to me.

— Pyry

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution