[swift-users] package graphroot error

2017-10-01 Thread Muhammad Tahir Vali via swift-users
Hello,

I've updated to swift 4.0 and downloaded a CL tool swiftenv . Mixing and
debugging with different versions , I may have messed up my swift
environment variables and ultimately deleted my swift-tools. How do I
safely default everything back to working form?

swift tools --version

error: unable to invoke subcommand:
/Library/Developer/Toolchains/swift-4.0-RELEASE.xctoolchain/usr/bin/swift-tools
(No such file or directory)


-- 
Best Regards,

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


[swift-users] bigintegers

2017-09-19 Thread Muhammad Tahir Vali via swift-users
hello,

im in a crypto class. we had to compute with big integers and i found out
swift 4 doesnt support BigIntegers but the new integer protocol can pave
the way to help create it.

I want to know how immediate the plans to implement it in the standard
library and if there was any help needed to create one. Some key points to
keep in mind would be helpful with swift context. Thank you!

I checked this out too! Pretty awesome
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md



-- 
Best Regards,

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


[swift-users] Error: Type 'Self.T' does not conform to protocol 'Equatable'

2017-07-10 Thread Muhammad Tahir Vali via swift-users
hey all,

just trying to figuring out a few workarounds for a problem I'm having. Im
having 2 errors both because of associatedtype.

*#1 can be found on the "Vertexable" protocol. This is a strange error
which should work but I'm guessing associatedtypes are causing trouble.
  *
*//error: Type 'Self.T' does not conform to protocol Equatable*

*#2 is me trying to create an array of "Vertexable" objects that can have
different data types since there are use-cases of graphs with different
data types. I can do exactly this when I remove the associatedtype "T" but
I would need to remove  EZNode as well and be forced to manually add it
in for the "EZVertex" class.  *

Error is shown at bottom of this message. You can also refer to
https://www.natashatherobot.com/swift-type-erasure/

for reference and try to create an array of "Pokemon"

Thank you in advance. Sorry if this was too bulky. Im just looking for
conceptual answers to workaround this or why compiler can't accept this.
My last option is to plainly remove both protocols but I find it quite
ironic if I would have to considering the philosophy of protocols.

*//Protocol to create a node*

*protocol** Nodeable : *Equatable*  {*

*associatedtype** T*

*var** data : T { **get* *set** }*

*}*


*//Value-based node*

*public* *struct** EZNode : **Nodeable** {*

*.*

*.*


*typealias** T = **Element*



*var** data : **T*



*init**(data: **T**) {*

*self**.**data** = data*

*}*



*}*

*//Protocol to create a vertex*

*protocol** Vertexable : Hashable {*

*.*

*.*

*associatedtype** T*


*var** node: *EZNode* { **get* *set** }*

*//error: Type 'Self.T' does not conform to protocol Equatable*


*func** getData() -> T*



*}*


*//Reference-based vertex*

*class** EZVertex : **Vertexable* *where* *Element**:
*Equatable* & *Hashable* {*



 *.*

*.*

*typealias** T = **Element*

*var** node: **EZNode**<**T**>*

*//alternative that requires manual entry since it doesnt belong to
"Vertexable" - var node: EZNod *



*var** hashValue: *Int* {*

*return* *"**\**(**self**.**index**) **\**(**self**.**node**)"**.*
hashValue

*}*



*init**(element: **Element**) {*

*self**.**node** = **EZNode**(data: element)*

*self**.**index** = index*

*}*



*static* *func** ==(lhs: **EZVertex**<**Element**>, rhs: **EZVertex**<*
*Element**>) -> *Bool* {*

*return** lhs.**node**.**data* ==* rhs.**node**.**data* &&* lhs.*
*index** == rhs.**index*

*}*



*func** getData() -> **Element** {*

*return* *node**.**data*

*}*



*}*


*let** node1 = **EZNode**(data: **1**)*

*let** node2 = **EZNode**(data: **10.0**)*

*let** vertex1 = **EZVertex**(element: **node1**.**data**, index: **1**)*

*let** vertex2 = **EZVertex**(element: **node2**.**data**, index: **2**)*


 *//protocol "Vertexable" can only be used a generic constraint because it
has Self or associatedtype requirements. *

*let** arr1 : [**Vertexable**] = [**vertex1**,**vertex2**]*


-- 
Best Regards,

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


[swift-users] Protocol Conformance

2017-06-19 Thread 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