Re: [swift-users] KeyPaths and PartialKeyPaths - when can you leave out the class?

[Karl Wagner via swift-users]

+1

An example I ran in to today:

func dumpKeys(of object: T, _ keypaths: PartialKeyPath...) {
  for kp in keypaths {
print("-", "\(kp): \(object[keyPath: kp])")
  }
}

Then in LLDB, I want to be able to write:

dumpKeys(of: context, \.invalidateEverything, \.invalidateDataSourceCounts)

But the PartialKeyPath expressions are considered ambiguous :(

- Karl

> On 12. Jan 2018, at 02:20, Kenny Leung via swift-users 
>  wrote:
> 
> Filed as https://bugs.swift.org/browse/SR-6740 
> 
> 
> -Kenny
> 
> 
>> On Jan 11, 2018, at 3:12 PM, Jordan Rose > > wrote:
>> 
>> I'm not sure whether it was supposed to be supported or not, but either way 
>> it's a reasonable feature request. Please file at bugs.swift.org 
>> .
>> 
>> Jordan
>> 
>> 
>>> On Jan 11, 2018, at 14:41, Kenny Leung via swift-users 
>>> > wrote:
>>> 
>>> Hi All.
>>> 
>>> I’d like to be lazy and leave out the classname on a key path whenever 
>>> possible. I thought that if PartialKeyPath was specified as the argument 
>>> type, that meant the compiler should be able to figure out what the class 
>>> is, but this does not seem to be the case.
>>> 
>>> Here’s an example that works.
>>> 
>>> class ThePath {
>>> var isWinding:Bool?
>>> }
>>> 
>>> func walk(aPath:T, forKey:PartialKeyPath) {
>>> }
>>> 
>>> func walkThePath(aPath:ThePath, forKey:PartialKeyPath) {
>>> }
>>> 
>>> func test() {
>>> let path = ThePath()
>>> walkThePath(aPath:path, forKey:\ThePath.isWinding)
>>> walk(aPath:path, forKey:\ThePath.isWinding)
>>> }
>>> 
>>> If you do this then it complains:
>>> 
>>> func test() {
>>> let path = ThePath()
>>> walkThePath(aPath:path, forKey:\.isWinding) // Expression type '()' is 
>>> ambiguous without more context
>>> walk(aPath:path, forKey:\.isWinding)// Type of expression is 
>>> ambiguous without more context
>>> }
>>> 
>>> Should I be able to do this?
>>> 
>>> Thanks!
>>> 
>>> -Kenny
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Start another program from Swift script

[Karl Wagner via swift-users]

These kinds of things live in Foundation, not the standard library:

import Foundation

let p = Process()
p.executableURL = URL(fileURLWithPath: "/bin/ps")
try p.run()

The Process class provides you with stdin/out/error handles for the process 
(https://developer.apple.com/documentation/foundation/process).
FileHandle also provides these standard streams for the current process 
(https://developer.apple.com/documentation/foundation/filehandle).

- Karl

> On 4. Jan 2018, at 17:03, Седых Александр via swift-users 
>  wrote:
> 
> Well, for example in Python we can run another program from interpreter by
>  
> import subprocess
> result = subprocess.run('ruby script.rb').stdout
>  
> My question is next:
> Can we do something from Swift file at runtime or maybe from terminal via REPL
>  
> And can you send me resource when I can read about work with stdin, stdout in 
> Swift, because is very small info in Documentation (Standard Library I/O)
> 
> -
> Alexandr
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Protocol Conformance

[Karl Wagner via swift-users]

> On 20. Jun 2017, at 01:38, Muhammad Tahir Vali via swift-users 
>  wrote:
> 
> Hey all,
> 
> I wanted to know if theres a work around for a problem I am having
> 
> lets say I have a protocol 
> 
> protocol Graphable : CustomStringConvertible, Sequence, Collection {
> var vertices : [AnyVertexable] { get set }
> var edges: [AnyEdge]? { get set }
>  
> 
> }
> 
> Then I have 2 classes that inherit from them 
> 
> class EZUndirectedGraph : Graphable {
> var vertices : [AnyVertexable] 
> var edges: [AnyEdge]? 
>  .
> }
> 
> class EZDirectedGraph : Graphable {
> var vertices : [AnyVertexable]
> var edges: [AnyEdge]? 
> // var edges : [AnyEdge]
> 
> }
> 
> Is there a way for me to make the "edges" variable in "EZDirectedGraph" to 
> NOT be an optional while still conforming to the same protocol? As one may 
> know, a condition for directed graphs requires there to be atleast 1 edge. 
> 
> Advice or alternative workarounds would be nice with respect of what I am 
> trying to do here with Graph Theory. 
> 
> My last 2 options were to either 
> 
> 1. Create separate protocols for the different types of graphs but there's 
> many types so I would be writing a lot of redundant code. 
> 
> 2. Leaving it how it is. Inserting an enum "TypeOfGraph" for the different 
> types of graphs and then computing its type with the help of the different 
> initializer methods. 
> 
> 
> 
> -- 
> Best Regards,
> 
> Muhammad T. Vali
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users



I don’t think that works, but in your case it would not be safe anyway. The 
(Optional-typed) property “edges” is mutable in the “Graphable” protocol — that 
means that anybody could take an EZDirectedGraph (where the property is 
non-optional), cast it to a Graphable, and set its “edges” property to nil. Or 
some generic code might do that.

Personally, I would recommend removing the optional. If you’re trying to 
represent the difference between possibly-empty-edges/not-empty-edges, the 
optional isn’t actually going to give you that safety. After all, there’s 
nothing in the type-system which says that EZDirectedGraph’s array is not 
empty. You would need to document that and add assertions when mutating.

If you really wanted to make it rigorously safe, you could create a 
NonEmptyArray struct which wraps an Array, intercepts mutation events and 
enforces that the underlying Array is never totally emptied. Then you would 
need to replace “edges” in Graphable with an associated type. That level of 
rigorous safety might not be required or even desired — on the other hand, it 
might help people to detect common bugs more easily. It all depends on your 
use-cases and your users.

- Karl

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

Re: [swift-users] Restricting associated values

[Karl Wagner via swift-users]

> On 19. Jun 2017, at 04:30, Nevin Brackett-Rozinsky via swift-users 
>  wrote:
> 
> Is there a way to restrict the associated values of an enum? For example, 
> suppose I have this type:
> 
> enum Angle {
> case radians(Double)
> case degrees(Double)
> }
> 
> I want to ensure that the radians values is always in [0, 2π) and the degrees 
> values is always in [0, 360). Ideally I would like to write an initializer 
> which is called when the user writes eg. “let x: Angle = .degrees(-45)” and 
> contains the logic to wrap the provided value into the allowed range (in this 
> case by adding a multiple of 360).
> 
> I don’t see a way to do it. Is this possible?
> 
> The closest I’ve found is to create auxiliary types such as
> 
> struct Degree { … }
> struct Radian { … }
> 
> and give them appropriate initializers, then use them for the associated 
> values. However that is undesirable because it adds an extra level of depth 
> to get at the actual numeric values.
> 
> Is there a better way?
> 
> Nevin
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users 
> 

I suggested a type like this when Xiaodi announced his maths library, but a 
more efficient implementation would look like this:

public struct Angle {
public let radians: T
public var degrees: T {
return (radians / .pi) * 180
}

public static func radians(_ rads: T) -> Angle {
return Angle(radians: rads)
}
public static func degrees(_ degs: T) -> Angle {
return Angle(radians: (degs / 180) * .pi)
}
}

Floating-points don’t have extra inhabitants, so the enum representation would 
occupy { float size + 1 byte } of storage, with the extra byte marking which 
enum case you have.

A better approach is to store a single, normalised value (in this case, the 
‘radians' value), and to provide initialisers which validate and normalise 
those input values. In your case, you wrap them to an allowed range. 

I think the best-practice advice in this situation would be to consider 
switching: will anybody need to switch over the cases of your enum? In this 
case, no - Angle is just a wrapper which statically verifies that the angle 
is in the expected “notation”; You want to put an angle of either notation in, 
and grab the same angle out in another notation. The underlying stored notation 
is an implementation detail, so a struct is better.

- Karl___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Restricting associated values

[Karl Wagner via swift-users]

> On 19. Jun 2017, at 20:03, Karl Wagner  wrote:
> 
> 
>> On 19. Jun 2017, at 04:30, Nevin Brackett-Rozinsky via swift-users 
>> > wrote:
>> 
>> Is there a way to restrict the associated values of an enum? For example, 
>> suppose I have this type:
>> 
>> enum Angle {
>> case radians(Double)
>> case degrees(Double)
>> }
>> 
>> I want to ensure that the radians values is always in [0, 2π) and the 
>> degrees values is always in [0, 360). Ideally I would like to write an 
>> initializer which is called when the user writes eg. “let x: Angle = 
>> .degrees(-45)” and contains the logic to wrap the provided value into the 
>> allowed range (in this case by adding a multiple of 360).
>> 
>> I don’t see a way to do it. Is this possible?
>> 
>> The closest I’ve found is to create auxiliary types such as
>> 
>> struct Degree { … }
>> struct Radian { … }
>> 
>> and give them appropriate initializers, then use them for the associated 
>> values. However that is undesirable because it adds an extra level of depth 
>> to get at the actual numeric values.
>> 
>> Is there a better way?
>> 
>> Nevin
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> 
> I suggested a type like this when Xiaodi announced his maths library, but a 
> more efficient implementation would look like this:
> 
> public struct Angle {
> public let radians: T
> public var degrees: T {
> return (radians / .pi) * 180
> }
> 
> public static func radians(_ rads: T) -> Angle {
> return Angle(radians: rads)
> }
> public static func degrees(_ degs: T) -> Angle {
> return Angle(radians: (degs / 180) * .pi)
> }
> }
> 
> Floating-points don’t have extra inhabitants, so the enum representation 
> would occupy { float size + 1 byte } of storage, with the extra byte marking 
> which enum case you have.
> 
> A better approach is to store a single, normalised value (in this case, the 
> ‘radians' value), and to provide initialisers which validate and normalise 
> those input values. In your case, you wrap them to an allowed range. 
> 
> I think the best-practice advice in this situation would be to consider 
> switching: will anybody need to switch over the cases of your enum? In this 
> case, no - Angle is just a wrapper which statically verifies that the 
> angle is in the expected “notation”; You want to put an angle of either 
> notation in, and grab the same angle out in another notation. The underlying 
> stored notation is an implementation detail, so a struct is better.
> 
> - Karl

Oh, and one thing to note is that by making static initialiser functions, you 
can still pass angles in to functions by calling ".degrees(90)”  or 
“.radians(.pi/4)”, so you kind-of emulate the convenience of using enums. IIRC, 
RawOptionSet does a similar trick.

The above struct is source-compatible with an equivalent enum representation; 
it all comes down to implementation details, and for this, the struct is more 
efficient.

- Karl___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] How to write a test against fixture resources from generated xcodeproj test bundle?

[Karl Wagner via swift-users]

> On 10. Jun 2017, at 04:02, Toshihiro Suzuki via swift-users 
>  wrote:
> 
> Hi Swift Community,
> I'm Toshihiro Suzuki and have a question about Swift Package Manager.
> I'm trying out with new Xcode9-beta.
> 
> When I generate a new xcodeproj like this, `Resources` directory is imported 
> as a folder reference in xcodeproj.
> ```
> $ swift -version
> Apple Swift version 4.0 (swiftlang-900.0.43 clang-900.0.22.8)
> Target: x86_64-apple-macosx10.9
> $ swift package init --type library
> $ mkdir -p Resources/Fixtures/
> $ touch Resources/Fixtures/test.txt
> $ swift package generate-xcodeproj
> ```
> 
> When I open the xcodeproj and hit Cmd+U, I want to access test.txt with code 
> like this.
> ```
> let path = Bundle(for: Swift4sampleTests.self).path(forResource: "test.txt", 
> ofType: nil)!
> let data = Data(contentsOf: URL(string: path)!)
> ```
> 
> To make it work, I need to manually
> - add Resources/ as a group, instead of folder reference.
> - add "Copy Files Phase" in Build Phase to copy test.txt as "Resources".
> 
> Can SwiftPM handle this use-case automatically?
> Or is there a way to access test resources from generated xcodeproj test 
> bundle?
> 
> Thanks,
> Toshihiro Suzuki
> -- 
> Toshihiro Suzuki
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

Swiftpm does not currently support resources - not in applications, libraries, 
or tests.

It’s a commonly-requested feature, though. I’m sure it will come in a future 
release.

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

Re: [swift-users] Swift 4 protocol with associatedtype conforming to itself

[Karl Wagner via swift-users]

> On 7. Jun 2017, at 11:29, Jens Persson via swift-users 
>  wrote:
> 
> I see, this quote from the introduction of SE-0142 is not to be taken 
> literally then:
> 
> For example, the SequenceType protocol could be declared as follows if the 
> current proposal was accepted:
> 
> protocol Sequence {
> associatedtype Iterator : IteratorProtocol
> associatedtype SubSequence : Sequence where SubSequence.Iterator.Element 
> == Iterator.Element
> ...
> }
> 
> Don't want to nitpick, but it's hard to follow Swift's evolution when 
> proposals like eg SE-0142 (and eg SE-0110) can have status "implemented"  
> even though they contain statements and examples like the above which simply 
> are not true (when compared to the compiler which supposedly implements the 
> proposal).
> 
> Is there somewhere I can see what *part(s)* of an "implemented" proposal are 
> *actually implemented*?
> 
> Otherwise, I think it would be less confusing if partly implemented proposals 
> were marked as such.
> 
> /Jens
> 

I think that’s just a poor example in the proposal. Constraining "SubSequence: 
Sequence" is not actually part of SE-0142.

As for implementation status, usually I check the changelog 
(https://github.com/apple/swift/blob/master/CHANGELOG.md 
)

- Karl___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Associatedtype Naming Conventions

[Karl Wagner via swift-users]

> On 7. Jun 2017, at 00:25, Dave Abrahams via swift-users 
>  wrote:
> 
> 
> on Wed May 31 2017, Steven Brunwasser  > wrote:
> 
>> Yes, I understand this. I was just wondering if there was a naming
>> convention I should use to differentiate them.
> 
> I would try to find something more specific and descriptive than
> “Container” and “Element” if you think there's a chance they would ever
> arise as associated types of the same type but with distinct identity.
> 
> Another possibility, if you think that might be about to happen, is that
> you're using conformance when you should use aggregation.  For example,
> an Int has everything it needs to be a Sequence and/or Iterator (n to
> infinity), a Collection (of numbers from zero to its bitWidth), etc.,
> but *should* it conform to those protocols?  IMO probably not.  If you
> find yourself hard pressed to describe what something *is* in a few
> words, it may be conforming to too many protocols.

Additionally, I find that when a type is representable in multiple overlapping 
ways (where “overlapping” is meant quite broadly), it can be good to create 
wrappers for those conformances.

For example, you might try:

Struct MyThing {
}

extension MyThing {

var foo: Foo { return MyThing.FooWrapper(self) }
var bar: Bar { return MyThing.BarWrapper(self)  }

struct FooWrapper: Foo {
let base: MyThing
init(_ wrapping: MyThing) { self.base = wrapping }

// Implement ‘Foo’ using data from ‘base’.
}
}

let something = MyThing()

takesAFoo(something.foo)
takesABar(something.bar)


This is analogous to how String is represented — the data is stored once, and 
there are multiple Collection conformances which interpret the data in 
different ways (as graphemes, or as a collection of non-character-boundary 
code-units in various encodings).___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] So how do you implement a NSTextStorage subclass in Swift?

[Karl Wagner via swift-users]

  
  
I've seen this before; I considered it something to be resolved in AppKit. 
Strings in Swift are values, and the framework expects it to be a reference. 
Since NSTextStorage is itself a reference-type and informs its delegate of 
changes, those frameworks should probably retain the NSTS itself and pull 
Strings out as-needed.
  
  
  

  
Once the new String model is done (long time yet), I would love it if Apple's 
CoreText team created a truly Swift (i.e. Protocol-based) NSTextStorage API. 
You wouldn't necessarily have to provide a stdlib String; any UTF16-encoded 
Unicode/StringProtocol instance could possibly suffice, allowing you to 
optimise storage through buffer-gaps and whatnot (doable today with 
NSMutableString subclass, but you can't subclass a struct).
  

  
- Karl
  
  
  

  
  
>   
> On Feb 10, 2017 at 10:51 pm,   (mailto:swift-users@swift.org)>  wrote:
>   
>   
>   
> Got some clarity on this from Apple folks on Twitter:   
> https://twitter.com/jtbandes/status/830159670559993856   
>
>   
> On Fri, Feb 10, 2017 at 12:54 PM, Michel Fortin   (mailto:michel.for...@michelf.ca)>  wrote:
>   
> >   
> > I did file one (30314719). I might not have explained the problem clearly 
> > enough, I suppose, because at the time I was misinterpreting the API 
> > contract thinking it was the new AppKit Touch Bar stuff that was violating 
> > it instead. That bug now sits closed and I hesitate opening a new bug for 
> > the same problem just to ask it to be fixed in another way.   Meanwhile I 
> > found an acceptable workaround that I attached to the existing bug report 
> > in addition and I posted all this to the list. Hopefully someone at the 
> > right place will notice.  
> >
> >   
> > But yeah... maybe I should file another bug, against Foundation's Swift 
> > interface this time, since NSTextStorage's string property comes from 
> > NSAttributedString. I'll think about it.  
> >   
> >
> >   
> >
> >   
> >   
> > >   
> > > Le 10 févr. 2017 à 11:36, Jacob Bandes-Storch   > > (mailto:jtban...@gmail.com)>  a écrit :
> > >   
> > >   
> > >   
> > > This seems like a bug (missing feature?) in how the API is imported for 
> > > Swift. You might consider filing a Radar.
> > >   
> > >   
> > >   
> > >   
> > > On Thu, Feb 9, 2017 at 3:12 PM Michel Fortin via swift-users  
> > >   wrote:
> > >   
> > > > The `string` property of `NSTextStorage` is of type `String`, but the 
> > > > contract it must implement is that it should return the backing store 
> > > > of the attributed string (the underlying `NSMutableString` used as the 
> > > > backing store). It seems to me that this makes it impossible to 
> > > > implement correctly a subclass of `NSTextStorage` in Swift, because 
> > > > Swift automatically wraps the `NSString` into a `String` and the 
> > > > underlying mutable storage is not passed around.
> > > >   
> > > >  Here's the documentation for that method:
> > > >   
> > > > https://developer.apple.com/reference/foundation/nsattributedstring/1412616-string
> > > >   
> > > >  In case the contract isn't clear from the documentation (it wasn't for 
> > > > me), I got a confirmation as a response in radar 30314719:
> > > >   >  It’s returning a copy of the backing store, but the contract is 
> > > > actually returning the backing store string. The copy storage 
> > > > declaration in the property spec is only used for setter implementation.
> > > >   
> > > >  So looks like this is impossible to model correctly in Swift due to 
> > > > the automatic bridging to `String`. Some APIs in AppKit expect the 
> > > > `NSString` they receive to mutate when mutating the text storage (touch 
> > > > bar suggestions in `NSTextView`) and will do bad things this isn't the 
> > > > case.
> > > >   
> > > >  Obviously, I can work around this by writing some Objective-C code, 
> > > > but it'd be better if I could avoid splitting the class implementation 
> > > > between two languages. There's another way using swizzling to map the 
> > > > Objective-C method to a Swift implementation of the same method that 
> > > > has the correct signature, and that's probably what I'll end up doing 
> > > > unless a better solution can be pointed out to me.
> > > >   
> > > >   
> > > >  --
> > > >  Michel Fortin
> > > >   https://michelf.ca (https://michelf.ca/)
> > > >   
> > > >  ___
> > > >  swift-users mailing list
> > > >   swift-users@swift.org (mailto:swift-users@swift.org)
> > > >   https://lists.swift.org/mailman/listinfo/swift-users
> > > >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >  --   
> >  Michel Fortin   
> >   https://michelf.ca
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
> >   
>___ swift-users mailing

Re: [swift-users] Weak references in generic types

[Karl Wagner via swift-users]

  
  
What I'm trying to say is that P is a protocol and not a class, so it does not 
conform to AnyObject.   P does not conform to P.
  

  
It is in some sense a language limitation that we cant express what you're 
talking about. If we weren't using mailing lists it would be easier to search 
for "protocol self-conformance" on swift-evo and to read the earlier discussion 
about it.   
  

  

  
  
>   
> On Sep 2, 2016 at 1:04 am,  mailto:howard.lov...@gmail.com)>  
> wrote:
>   
>   
> @Karl,  
>
>   
> You say "In the second example, you’re creating WeakReference. P does not 
> conform to P or to AnyObject.", but P does conform to AnyObject.
>   
>
>   
> I suspect it is a compiler limitation/ bug.   
>   
>
>   
>   -- Howard.   
>
>  On Thursday, 1 September 2016, Karl   (mailto:razie...@gmail.com)>  wrote:
>   
> >   
> >
> >   
> >   
> > >   
> > > On 1 Sep 2016, at 03:23, Howard Lovatt via swift-users  
> > >  > > (javascript:_e(%7B%7D,'cvml','swift-users@swift.org');)>  wrote:
> > >   
> > >   
> > >   
> > > Playing around I found that if you make the protocol @objc instead of 
> > > AnyObject then it works :). EG:  
> > >
> > >   
> > > >   
> > > > struct WeakReference  {
> > > >   
> > > >weak var value: T?
> > > >   
> > > > }
> > > >   
> > > > @objc protocol P { // Note @objc, class or AnyObject does not work
> > > >   
> > > >var i: Int { get }
> > > >   
> > > > }
> > > >   
> > > > class CP: P {
> > > >   
> > > >var i: Int = 0
> > > >   
> > > > }
> > > >   
> > > > let weakPs: [WeakReference] = [WeakReference(value: cP)] // Note 
> > > > typed as `[WeakReference]`
> > > >   
> > > > print("P: \(weakPs[0].value!.i)") // 0
> > > >   
> > >   
> > >   
> > >
> > > Not a 'pure' Swift solution :(, but OK in my case.
> > >
> > >   
> > >   
> > >   
> > >
> > >   
> > >   
> > >-- Howard.
> > > 
> > >   
> > > On 29 August 2016 at 16:21, Howard Lovatt   > > (javascript:_e(%7B%7D,'cvml','howard.lov...@gmail.com');)>  wrote:
> > >   
> > > >   
> > > > Hi,  
> > > >
> > > >   
> > > > I am wanting to use weak references in generic data structures; in the 
> > > > example below Array, but in general any generic type. I can almost get 
> > > > it to work :(
> > > >   
> > > >
> > > >   
> > > > My experiments started off well; the following works:
> > > >   
> > > >
> > > >   
> > > > >   
> > > > > // Array of weak references OK
> > > > >   
> > > > > struct WeakReference  {
> > > > >   
> > > > >weak var value: T?
> > > > >   
> > > > > }
> > > > >   
> > > > > class C {
> > > > >   
> > > > >var i: Int = 0
> > > > >   
> > > > > }
> > > > >   
> > > > > let c = C() // Strong reference to prevent collection
> > > > >   
> > > > > let weakCs = [WeakReference(value: c)] // OK
> > > > >   
> > > > > print("C: \(weakCs[0].value!.i)") // 0
> > > > >   
> > > >   
> > > >  I can add a protocol:  
> > > >
> > > >   
> > > > >   
> > > > > // Array of weak references that implements a protocol OK
> > > > >   
> > > > > protocol P: AnyObject { // Note AnyObject
> > > > >   
> > > > >var i: Int { get }
> > > > >   
> > > > > }
> > > > >   
> > > > > class CP: P {
> > > > >   
> > > > >var i: Int = 0
> > > > >   
> > > > > }
> > > > >   
> > > > > let cP = CP() // Strong reference to prevent collection
> > > > >   
> > > > > let weakCPs = [WeakReference(value: cP)] // OK
> > > > >   
> > > > > print("CP: \(weakCPs[0].value!.i)") // 0
> > > > >   
> > > >   
> > > >   
> > > >
> > > >   
> > > > But when I want an array of weak references to the protocol I get an 
> > > > error:
> > > >   
> > > >
> > > > 
> > > > >   
> > > > > // Array of weak references of a protocol not OK
> > > > >   
> > > > > let weakPs: [WeakReference] = [WeakReference(value: cP)] // Using 
> > > > > 'P' as a concrete type conforming to protocol 'AnyObject' is not 
> > > > > supported
> > > > >   
> > > > > print("P: \(weakPs[0].value!.i)") // 0
> > > > >   
> > > >   
> > > >   
> > > >
> > > >   
> > > > Is there something I have missed?
> > > >   
> > > >
> > > >   
> > > > The error message, "Using 'P' as a concrete type conforming to protocol 
> > > > 'AnyObject' is not supported", implies that it is a temporary 
> > > > limitation of the compiler; is this going to be fixed? Should I lodge a 
> > > > bug report?
> > > >   
> > > >
> > > >   
> > > > Thanks in advance for any advice,
> > > >   
> > > >
> > > >   
> > > >   
> > > >-- Howard.
> > > >   
> > >  ___
> > >  swift-users mailing list
> > >   swift-users@swift.org 
> > > (javascript:_e(%7B%7D,'cvml','swift-users@swift.org');)
> > >   https://lists.swift.org/mailman/listinfo/swift-users
> > > 
> >   
> > Your problem is protocol self-conformance. In the first example, you’re 
> > creating WeakReference. CP conforms to P and to AnyObject. In the 
> >