Re: [swift-users] Protocol conformance error

[Nevin Brackett-Rozinsky via swift-users]

Because it would break this:

func foo (c: T, a: U) { c.test(a) }

Nevin


On Wed, Jan 17, 2018 at 2:29 AM, Roshan via swift-users <
swift-users@swift.org> wrote:

> Hi,
>
> Here is some sample code that gives a protocol conformance error in a
> playground:
>
> protocol A {}
> protocol B: A {}
>
> protocol C {
> func test(x: A)
> }
>
> class M: C {
> func test(x: B) {}
> }
>
> Is there a reason why the compiler doesn't infer that ((B) -> ())
> matches ((A) -> ()) because of inheritance?
>
> --
> Warm regards
> Roshan
> ___
> 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] protocol conformance question

[Swarbrick, Frank via swift-users]

Is there a way I can specify that all integer types conform to MyProtocol 
without naming them explicitly like this??

protocol MyProtocol {}
extension String: MyProtocol {}
extension Int: MyProtocol {}
extension UInt8: MyProtocol {}
[...]

I tried the following:
extension FixedWidthInteger: MyProtocol {}
but get "error: extension of protocol 'FixedWidthInteger' cannot have an 
inheritance clause".

Thanks,
Frank


The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above. If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited. If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication. Thank you.
___
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

[swift-users] Protocol Conformance

[Muhammad Tahir Vali via swift-users]

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

Re: [swift-users] Protocol conformance failure

[Slava Pestov via swift-users]

Worth mentioning that @objc protocols do conform to themselves as long as they 
do not have static methods or initializer requirements. However this may be too 
heavy-handed if a simple overload can do the trick.

Slava

> On Mar 9, 2017, at 1:10 PM, Guillaume Lessard via swift-users 
>  wrote:
> 
> 
>> On Mar 9, 2017, at 12:46, Edward Connell via swift-users 
>>  wrote:
>> 
>> // Everything compiles fine until this
>> someFunc(items: items)
> 
> This is a frequent pain point: protocol existentials cannot stand in for the 
> protocol they represent.
> Your function wants a concrete type that conforms to ItemProtocol, but an 
> array of disparate types which happen to separately conform to ItemProtocol 
> does not do that.
> 
> You will need to overload thusly:
> 
> func someFunc(items: [ItemProtocol]) {
>  for item in items {
>print(item.message)
>  }
> }
> 
> until, someday, this pain point is resolved.
> 
> Cheers,
> Guillaume Lessard
> 
> ___
> 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 failure

[Guillaume Lessard via swift-users]

> On Mar 9, 2017, at 12:46, Edward Connell via swift-users 
>  wrote:
> 
> // Everything compiles fine until this
> someFunc(items: items)

This is a frequent pain point: protocol existentials cannot stand in for the 
protocol they represent.
Your function wants a concrete type that conforms to ItemProtocol, but an array 
of disparate types which happen to separately conform to ItemProtocol does not 
do that.

You will need to overload thusly:

func someFunc(items: [ItemProtocol]) {
  for item in items {
print(item.message)
  }
}

until, someday, this pain point is resolved.

Cheers,
Guillaume Lessard

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

[swift-users] Protocol conformance failure

[Edward Connell via swift-users]

The error says ItemProtocol does not conform to ItemProtocol.
That doesn't make sense. It seems this should work fine.

// It's all clean until the last line
protocol ItemProtocol : class {
var message: String { get }
}

// heterogenious types
class A : ItemProtocol {
var message = "A"
}

class B : ItemProtocol {
var message = "B"
}


var items: [ItemProtocol] = [A(), B()]

func someFunc(items: [T]) {
for item in items {
print(item.message)
}
}

// Everything compiles fine until this
someFunc(items: items)
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users