Re: [swift-users] Overload Resolution of Binary Operators

[Rien via swift-users]

I seem to remember that while it is possible to define, the compiler will yield 
an error if you try to use the functions (“cannot resolve”).

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 14 Nov 2016, at 23:05, Toni Suter via swift-users  
> wrote:
> 
> Hi,
> 
> I would have expected that the following code reports an error, because
> of ambiguous function overloads:
> 
> infix operator ***: MultiplicationPrecedence
> infix operator +++: AdditionPrecedence
> 
> func ***(x: Int, y: Int) -> String {
>   print("f1")
>   return ""
> }
> 
> func ***(x: Int, y: Int) -> Int {
>   print("f2")
>   return 0
> }
> 
> func +++(x: String, y: Int) -> Int {
>   print("f3")
>   return 0
> }
> 
> func +++(x: Int, y: Int) -> Int {
>   print("f4")
>   return 0
> }
> 
> let result = 0 *** 4 +++ 0// prints f2 and f4
> 
> 
> As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
> f2 + f4.
> I thought that these two solutions get an "equivalent score" and therefore 
> there would
> be a compile error. However, that's not the case. Instead, the type checker 
> picks
> f2 and f4.
> 
> So, I guess my question is, whether there is some rule, that prefers
> operators, which have the same argument types and the same return type
> or whether this is simply a bug.
> 
> Thanks and best regards,
> Toni
> ___
> 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] Reflection in Swift 3?

[Rick Mann via swift-users]

Thanks, David. That's interesting as a thought exercise, but doesn't really get 
me away from having switch statements. I'll probably end up just "slightly 
polluting" my classes by adding extension methods to create the appropriate 
auxiliary classes. Sure wish Swift supported optional methods without @objc (I 
guess it's not that big a deal to use @objc).

> On Nov 13, 2016, at 11:19 , David Sweeris  wrote:
> 
> 
>> On Nov 13, 2016, at 1:55 AM, Rick Mann  wrote:
>> 
>> 
>>> On Nov 12, 2016, at 22:47 , David Sweeris  wrote:
>>> 
>>> 
 On Nov 13, 2016, at 00:38, Rick Mann via swift-users 
  wrote:
 
 So, it seems there's still no way to do something like instantiate a class 
 given only its name (as a String)?
 
 In my situation, I have a number of subclasses (or protocol 
 implementations), which parallel some other class hierarchy. I need to 
 dynamically create one based on the name of another. I don't want the 
 latter classes to "know" anything about the former.
>>> 
>>> Not that I know of... If this is all your code, can you fake it by 
>>> switching over the type's name?
>> 
>> Yeah, it just happens in a few places, would be nice to write the code once 
>> and then just ensure classes exist. I know I could do it subclassing 
>> NSObject, but Swift really ought to have proper reflection.
> 
> Reflection is on the todo list (although I can’t recall if it’s in-scope for 
> Swift 4).
> 
> There’s also the possibility of putting the names of the classes you want to 
> instantiate into an enum. In fact, if all the classes in question have a 
> common superclass, you could this:
> class MyAwesomeSuperClass { required init() {} }
> class MyAwesomeSubClass : MyAwesomeSuperClass {}
> class Whatever : MyAwesomeSuperClass {}
> class Etc : Whatever {}
> enum ClassNames : String {
> //Unfortunately the value of each case has to be a literal, so
> //you can’t just say `case etc = "\(Etc.self)"`
> case myAwesomeSuperClass = "MyAwesomeSuperClass"
> case myAwesomeSubClass = "MyAwesomeSubClass"
> case whatever = "Whatever"
> case etc = "Etc"
> init(_ instance: MyAwesomeSuperClass) { self = ClassNames.init(rawValue: 
> "\(type(of: instance))")! }
> init(_ type: MyAwesomeSuperClass.Type) { self = ClassNames.init(rawValue: 
> "\(type)")! }
> var type: MyAwesomeSuperClass.Type {
> switch self {
> case .myAwesomeSuperClass:  return MyAwesomeSuperClass.self
> case .myAwesomeSubClass:return MyAwesomeSubClass.self
> case .whatever: return Whatever.self
> case .etc:  return Etc.self
> }
>}
> }
> var etc = Etc()
> var className = ClassNames(etc)
> var newEtc = className.type.init()
> 
> The same trick works if all the types in question conform to the same 
> protocol, too:
> protocol MyAwesomeProtocol {
> init()
> func toIntMax() -> IntMax
> }
> extension Int : MyAwesomeProtocol {}
> struct Five : MyAwesomeProtocol { func toIntMax() -> IntMax { return 5 } }
> enum ProtocolNames : String {
> case five = "Five"
> case int = "Int"
> init(_ instance: MyAwesomeProtocol) { self = ProtocolNames.init(rawValue: 
> "\(type(of: instance))”)! }
> init(_ type: MyAwesomeProtocol.Type) { self = 
> ProtocolNames.init(rawValue: "\(type)")! }
> var type: MyAwesomeProtocol.Type {
> switch self {
> case .five: return Five.self
> case .int:  return Int.self
> }
> }
> }
> var five = Five()
> var fiveName = ProtocolNames(five)
> var newFive = fiveName.type.init()
> 
> Either way, though, you’ll have to do something like if let nf = newFive as? 
> Int {…} if you want to use any functionality that isn’t explicitly in the 
> superclass or protocol.
> 
> It certainly involves some boilerplate code, but it also has the advantages 
> of validating the name before you try to use it and ensuring that any switch 
> statements can actually handle all the classes. 
> 
> - Dave Sweeris


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-users] Decimal imported as NSDecimal not NSDecimalNumber in Swift 3 to Objective C

[Nevin Brackett-Rozinsky via swift-users]

Literals in Swift do not inherently have a type (at least conceptually).
They are simply literals.

The compiler will interpret them as whatever ExpressibleBy_Literal type
is required to make the expression sensible.

There are default types which literals will become if no type information
is available: a string literal becomes String, a floating point literal
becomes Double, and so forth. But the literals themselves do not have a
type, and will become whatever type makes sense in context.

Nevin


On Mon, Nov 14, 2016 at 4:59 PM, Chris Anderson via swift-users <
swift-users@swift.org> wrote:

> Thanks for that follow up, I’m still a little confused at why one
> direction works and the other does not, but I’m getting there.
>
> I’ve found another issue I’ll bug report, but it’s along the same lines
> and wanted to run it by this thread. If I have an NSDecimalNumber, in
> Swift, and perform math on a literal value, (product) the code compiles. If
> I assign that value to a variable, or use any of the other Decimal/Double
> types, I cannot compile. I would expect a Double to not work, but I would
> expect ‘Decimal’ to work, in this case, as I’m not crossing the Objective C
> border. And, I’m confused how using the literal ‘2.0’ is interpreted as an
> NSDecimalNumber, and works in the ‘product’ stop, but I would expect the
> compiler to try and make it into a Double, as it does on the ‘test’
> variable.
>
> let value = NSDecimalNumber(value: 2)
> let test = 2.0   //
> double
> let product = value.multiplying(by: 2.0)  // compiles
> let x = value.multiplying(by: Decimal(2.0)) // does not compile
> let y = value.multiplying(by: Double(2.0))   // does not compile
> let z = value.multiplying(by: test)// does not
> compile
>
> Best,
> Chris Anderson
>
> On Nov 11, 2016, at 6:07 PM, Philippe Hausler  wrote:
>
>
> NSDecimal is not toll free bridged, but it does have a bridge to
> NSDecimalNumber.
>
> So take this for example:
>
> @objc class Exam: NSObject {
> var grade: Double = 90.0
> }
>
> It would be reasonable to expect that is exposed in objc as:
>
> @interface Exam : NSObject
> @property double grade;
> @end
>
> and not:
>
> @interface Exam : NSObject
> @property NSNumber *grade;
> @end
>
> As it stands this is exposing as the structural type since that structural
> type comes from objective-c. Unlike String or Dictionary that have direct
> counterparts - NSDecimal and NSDecimalNumber both are sourced from the
> objective-c headers. That being said an API exposed in objc as returning a
> NSDecimalNumber should be exposed into swift as returning a Decimal (the
> struct NSDecimal). So if Exam was implemented in objc as such:
>
> @interface Exam : NSObject
> @property NSDecimalNumber *grade;
> @end
>
> that should be imported into swift as:
>
> class Exam : NSObject {
> var grade : Decimal
> }
>
> On Nov 11, 2016, at 2:58 PM, Adam C. Lickel via swift-users <
> swift-users@swift.org> wrote:
>
> NSDecimal has toll-free bridging with NSDecimalNumber so you can still do
> as casting when talking to an Objective-C API.
>
> On Nov 11, 2016, at 2:56 PM, Chris Anderson via swift-users <
> swift-users@swift.org> wrote:
>
> Sure thing. Yeah, ideally the bridging would be fixed, but at the least,
> correcting the documentation will be a good start. Will file, thanks.
>
> Best,
> Chris Anderson
>
> On Nov 11, 2016, at 5:55 PM, Tony Parker  wrote:
>
> Hi Chris,
>
> Can you file a radar or JIRA for us on this? It looks like something
> should be fixed in the documentation at least, or perhaps in the bridging.
>
> - Tony
>
> On Nov 11, 2016, at 1:46 PM, Chris Anderson via swift-users <
> swift-users@swift.org> wrote:
>
> I'm having problems with the type conversion between a Swift `Decimal` and
> an Objective C `NSDecimalNumber`.
>
> If I have the Swift class:
>
> @objc class Exam: NSObject {
> var grade: Decimal = 90.0
> }
>
> And try to use that Swift class in Objective C,
>
> Exam *exam = [[Exam alloc] init];
> NSDecimalNumber *result = [[NSDecimalNumber zero]
> decimalNumberByAdding:grade.value];
>
> I get the error:
>
> Sending 'NSDecimal' to parameter of incompatible type 'NSDecimalNumber *
> _Nonnull'
>
> as it seems like `grade` is being treated as an `NSDecimal` not an
> `NSDecimalNumber`. This seems incorrect as per
> https://developer.apple.com/reference/foundation/nsdecimalnumber it says
>
> "The Swift overlay to the Foundation framework provides the Decimal
> structure, which bridges to the NSDecimalNumber class. The Decimal value
> type offers the same functionality as the NSDecimalNumber reference type,
> and the two can be used interchangeably in Swift code that interacts with
> Objective-C APIs. This behavior is similar to how Swift bridges standard
> string, numeric, and collection types to their corresponding 

Re: [swift-users] Overload Resolution of Binary Operators

[Mark Lacey via swift-users]

> On Nov 14, 2016, at 2:05 PM, Toni Suter via swift-users 
>  wrote:
> 
> Hi,
> 
> I would have expected that the following code reports an error, because
> of ambiguous function overloads:
> 
> infix operator ***: MultiplicationPrecedence
> infix operator +++: AdditionPrecedence
> 
> func ***(x: Int, y: Int) -> String {
>   print("f1")
>   return ""
> }
> 
> func ***(x: Int, y: Int) -> Int {
>   print("f2")
>   return 0
> }
> 
> func +++(x: String, y: Int) -> Int {
>   print("f3")
>   return 0
> }
> 
> func +++(x: Int, y: Int) -> Int {
>   print("f4")
>   return 0
> }
> 
> let result = 0 *** 4 +++ 0// prints f2 and f4
> 
> 
> As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
> f2 + f4.
> I thought that these two solutions get an "equivalent score" and therefore 
> there would
> be a compile error. However, that's not the case. Instead, the type checker 
> picks
> f2 and f4.
> 
> So, I guess my question is, whether there is some rule, that prefers
> operators, which have the same argument types and the same return type
> or whether this is simply a bug.

It’s a bug, and one that I’m aware of, but I’m not aware of anything in JIRA 
for it. Do you mind opening an issue there and assigning it to me?

Mark

> 
> Thanks and best regards,
> Toni
> ___
> 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] Overload Resolution of Binary Operators

[David Sweeris via swift-users]

> On Nov 14, 2016, at 16:05, Toni Suter via swift-users  
> wrote:
> 
> Hi,
> 
> I would have expected that the following code reports an error, because
> of ambiguous function overloads:
> 
> infix operator ***: MultiplicationPrecedence
> infix operator +++: AdditionPrecedence
> 
> func ***(x: Int, y: Int) -> String {
>   print("f1")
>   return ""
> }
> 
> func ***(x: Int, y: Int) -> Int {
>   print("f2")
>   return 0
> }
> 
> func +++(x: String, y: Int) -> Int {
>   print("f3")
>   return 0
> }
> 
> func +++(x: Int, y: Int) -> Int {
>   print("f4")
>   return 0
> }
> 
> let result = 0 *** 4 +++ 0// prints f2 and f4
> 
> 
> As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
> f2 + f4.
> I thought that these two solutions get an "equivalent score" and therefore 
> there would
> be a compile error. However, that's not the case. Instead, the type checker 
> picks
> f2 and f4.
> 
> So, I guess my question is, whether there is some rule, that prefers
> operators, which have the same argument types and the same return type
> or whether this is simply a bug.

Odd... Perhaps the compiler is convinced the result of the *** operation needs 
to be an Int? Dunno why that would be, though.

What happens if you split it up into two statements?

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

[swift-users] Overload Resolution of Binary Operators

[Toni Suter via swift-users]

Hi,

I would have expected that the following code reports an error, because
of ambiguous function overloads:

infix operator ***: MultiplicationPrecedence
infix operator +++: AdditionPrecedence

func ***(x: Int, y: Int) -> String {
print("f1")
return ""
}

func ***(x: Int, y: Int) -> Int {
print("f2")
return 0
}

func +++(x: String, y: Int) -> Int {
print("f3")
return 0
}

func +++(x: Int, y: Int) -> Int {
print("f4")
return 0
}

let result = 0 *** 4 +++ 0  // prints f2 and f4


As far as I can tell, there are two possible overload resolutions: f1 + f3 or 
f2 + f4.
I thought that these two solutions get an "equivalent score" and therefore 
there would
be a compile error. However, that's not the case. Instead, the type checker 
picks
f2 and f4.

So, I guess my question is, whether there is some rule, that prefers
operators, which have the same argument types and the same return type
or whether this is simply a bug.

Thanks and best regards,
Toni___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Decimal imported as NSDecimal not NSDecimalNumber in Swift 3 to Objective C

[Chris Anderson via swift-users]

Thanks for that follow up, I’m still a little confused at why one direction 
works and the other does not, but I’m getting there.

I’ve found another issue I’ll bug report, but it’s along the same lines and 
wanted to run it by this thread. If I have an NSDecimalNumber, in Swift, and 
perform math on a literal value, (product) the code compiles. If I assign that 
value to a variable, or use any of the other Decimal/Double types, I cannot 
compile. I would expect a Double to not work, but I would expect ‘Decimal’ to 
work, in this case, as I’m not crossing the Objective C border. And, I’m 
confused how using the literal ‘2.0’ is interpreted as an NSDecimalNumber, and 
works in the ‘product’ stop, but I would expect the compiler to try and make it 
into a Double, as it does on the ‘test’ variable. 

let value = NSDecimalNumber(value: 2)
let test = 2.0   // double
let product = value.multiplying(by: 2.0)  // compiles
let x = value.multiplying(by: Decimal(2.0)) // does not compile
let y = value.multiplying(by: Double(2.0))   // does not compile
let z = value.multiplying(by: test)// does not compile

Best,
Chris Anderson

> On Nov 11, 2016, at 6:07 PM, Philippe Hausler  wrote:
> 
> 
> NSDecimal is not toll free bridged, but it does have a bridge to 
> NSDecimalNumber.
> 
> So take this for example:
> 
> @objc class Exam: NSObject {
> var grade: Double = 90.0
> }
> 
> It would be reasonable to expect that is exposed in objc as:
> 
> @interface Exam : NSObject
> @property double grade;
> @end
> 
> and not:
> 
> @interface Exam : NSObject
> @property NSNumber *grade;
> @end
> 
> As it stands this is exposing as the structural type since that structural 
> type comes from objective-c. Unlike String or Dictionary that have direct 
> counterparts - NSDecimal and NSDecimalNumber both are sourced from the 
> objective-c headers. That being said an API exposed in objc as returning a 
> NSDecimalNumber should be exposed into swift as returning a Decimal (the 
> struct NSDecimal). So if Exam was implemented in objc as such:
> 
> @interface Exam : NSObject
> @property NSDecimalNumber *grade;
> @end
> 
> that should be imported into swift as:
> 
> class Exam : NSObject {
>   var grade : Decimal
> }
> 
>> On Nov 11, 2016, at 2:58 PM, Adam C. Lickel via swift-users 
>> > wrote:
>> 
>> NSDecimal has toll-free bridging with NSDecimalNumber so you can still do as 
>> casting when talking to an Objective-C API.
>> 
>>> On Nov 11, 2016, at 2:56 PM, Chris Anderson via swift-users 
>>> > wrote:
>>> 
>>> Sure thing. Yeah, ideally the bridging would be fixed, but at the least, 
>>> correcting the documentation will be a good start. Will file, thanks.
>>> 
>>> Best,
>>> Chris Anderson
>>> 
 On Nov 11, 2016, at 5:55 PM, Tony Parker > wrote:
 
 Hi Chris,
 
 Can you file a radar or JIRA for us on this? It looks like something 
 should be fixed in the documentation at least, or perhaps in the bridging.
 
 - Tony
 
> On Nov 11, 2016, at 1:46 PM, Chris Anderson via swift-users 
> > wrote:
> 
> I'm having problems with the type conversion between a Swift `Decimal` 
> and an Objective C `NSDecimalNumber`.
> 
> If I have the Swift class:
> 
> @objc class Exam: NSObject {
> var grade: Decimal = 90.0
> }
> 
> And try to use that Swift class in Objective C, 
> 
> Exam *exam = [[Exam alloc] init];
> NSDecimalNumber *result = [[NSDecimalNumber zero] 
> decimalNumberByAdding:grade.value];
> 
> I get the error:
> 
> Sending 'NSDecimal' to parameter of incompatible type 'NSDecimalNumber * 
> _Nonnull'
> 
> as it seems like `grade` is being treated as an `NSDecimal` not an 
> `NSDecimalNumber`. This seems incorrect as per 
> https://developer.apple.com/reference/foundation/nsdecimalnumber 
>  it 
> says 
> 
> "The Swift overlay to the Foundation framework provides the Decimal 
> structure, which bridges to the NSDecimalNumber class. The Decimal value 
> type offers the same functionality as the NSDecimalNumber reference type, 
> and the two can be used interchangeably in Swift code that interacts with 
> Objective-C APIs. This behavior is similar to how Swift bridges standard 
> string, numeric, and collection types to their corresponding Foundation 
> classes."
> 
> So I'm not sure if 1) I'm doing something wrong. 2) there's an error in 
> the documentation or 3) this is a Swift bug. Number 1 on that list is 

Re: [swift-users] Optimising Set comparisons

[Nial Giacomelli via swift-users]

Many thanks to Tim for suggesting isSubset, which I had somehow missed
while browsing the documentation.

To answer Dave's questions: unfortunately the Set comparisons aren't an
ideal candidate for asynchronous work. The comparisons take place as part
of a CSS-like styling phase, whereby a number of Sets (the stylesheet
definitions) are compared against many thousands of other Sets (the class
lists for each styleable object). While I believe the Int comparisons would
undoubtedly be faster, I'm likely to lose even more time calculating the
hashValues for each Set.

I believe the use of isSubset as well as some result caching (storing
matches for subsequent queries including identical class lists) is likely
to result in a decent speed improvement. Thank you both for taking the time
to respond.

And if anyone has any suggestions for alternative approaches I'm all ears
:-)

On Sun, Nov 13, 2016 at 11:49 PM, David Sweeris  wrote:

>
> On Nov 13, 2016, at 1:58 PM, Nial Giacomelli via swift-users <
> swift-users@swift.org> wrote:
>
> Using Swift 3 I have a function that's called extremely frequently and is
> appearing regularly in Profiler runs. The function takes two Set
> instances and simply attempts to determine whether all items from Set A are
> present in Set B (it's important to note that Set B may well contain
> additional items).
>
> I've attempted to approach the problem in two ways:
>
> let diff = a.subtracting(b)
> guard diff.count == 0 else { return false }
>
> And also by simply iterating over the contents of Set A, like so:
>
> for item in a {
> if !b.contains(item) {
> return false
> }
> }
>
> Both ultimately end up spending the majority of their time in String._
> compareDeterministicUnicodeCollaton(String) -> Int. Which makes sense,
> given what I'm doing - but ideally I'd like to come up with a more
> efficient way of performing the above check. Swift's String representation
> is incredibly robust, but for my needs the strings could be adequately
> represented in ASCII encoding. I've also considered storing and comparing
> the hashValue of the strings, to speed up comparisons...
>
> Hopefully this is an acceptable question for this mailing list. I'm aware
> that this may not be a Swift-specific question and could well be solved
> with a more efficient data structure or approach, but I'd really appreciate
> some input from more experienced Swift developers :-)
>
>
> How often do the sets change? And where do you get them from? I’m
> wondering, if there’s enough time between when you get the strings and when
> you need to know if setA is a subset of setB, could you somehow compute the
> answer asynchronously in a background thread or something? Strictly
> speaking it wouldn't be any less work, but if you can move it to where
> you’re waiting for user input or something you’ll probably get your answer
> sooner.
>
> Regarding how to get the answer using less work in the first place, I
> think you’re doing a tiny bit of extra work — just some allocation
> overhead, really — by calculating the set difference and checking that its
> count == 0, rather than just checking if a.isSubset(of: b). Beyond that,
> I’m not really sure… You might be able to do something with the strings’
> hash values. I mean, I don’t know if they really “work like that” (I’m
> quite foggy on how hash values are calculated and exactly what they’re
> suitable for… this might be a horrible idea), but if they do, comparing
> hash values (Ints) will definitely be faster than comparing Strings. I did
> some quick’n’dirty testing on my machine with some code very much like:
>
> let setA: Set = ["some", "set", "of", "random", "strings"]
> let setB: Set = ["some", "other", "set", "of", "strings"]
> let hashedA = Set(setA.map{$0.hashValue})
> let hashedB = Set(setB.map{$0.hashValue})
> setA.isSubset(of: setB)
> hashedA.isSubset(of: hashedB)
>
>
> The actual execution of hashedA.isSubset(of: hashedB) seems to be very
> roughly 2x faster than setA.isSubset(of: setB). However, if you include
> the overhead of calculating them, using hash values drops to about 5x
> *slower*. So unless you’d be reusing the hashed values a lot or
> something, I think you’re already doing about the least amount of work I
> can think of.
>
> - Dave Sweeris
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] A place where community meets: Swift news aggregator proposal

[Dmitri Pavlutin via swift-users]

Hi Swift enthusiasts!

My name is Dmitri Pavlutin. I'm a Swift enthusiast too!

I blog about Swift and JavaScript languages at https://rainsoft.io.

When I publish articles about Swift, one drawback (compared to
JavaScript situation) is the limited number of places where I can
share new articles. Such situation negatively affects the propagation
of new content about Swift.

In case of JavaScript, I have a big number of sites where to share. I
can submit to http://www.echojs.com/, https://jslive.com/,
http://javascriptkicks.com/ and https://www.javascript.com/news.
These sites bring a lot of benefits for bloggers (easier to gain
traffic), readers (much easier to discover valuable content) and as
result the popularity of JavaScript language itself.
echojs.com actually generates traffic to my blog comparable to twitter.com.

Swift should implement the same efficient strategy.
In my view, an aggregator (for Swift content only) brings the
following benefits:
- Easier for developers to find quality information about the language:
   * Newest articles, tutorials, books publishing, etc;
   * Language evolution announcements: new versions, hot proposals, etc;
   * Swift community news: conferences, meetups;
   * Promote the high-rated posts to top, by implement a voting system
(the way http://echojs.com does)
- Easier for bloggers to share their content and reach wider audience;
as result it stimulates to write more content about Swift;
Beneficial side effects:
- The backend side application must be written in Swift using Kitura,
Perfect or alternative;
- The application should be open sourced;
- Put efforts on code quality and performance. This should serve a
demonstration how comfortable Swift is for backend development.

The motto: "On Swift, about Swift, for Swift developers!"

Let's start the brainstorming:
- What do you think about the benefits of such a project?
- Why such an aggregator is better (or worse) than existing
alternatives like https://www.reddit.com/r/swift/?
- Maybe such a project is already in development. Do you know some?
- Swift needs you! Do you wish to participate?

Thank you, Dmitri.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] LLDB can't access the value of an associated type variable

[Trevör ANNE DENISE via swift-users]

Hello,

I have an issue with a project, I was trying to inspect the value of a constant 
of type [GeneType], this type is defined as an associatedtype of a protocol, so 
there is no explicit type for it, just a constraint to be Hashable :

> protocol GAStandardGenomeRepresentable {
>
>associatedtype GeneType:Hashable
>
>var standardRepresentation: [GeneType] { get }
>
>init(standardRepresentation:[GeneType])
>
>
>
> }

 Unfortunately, inside of Xcode debugger or even by typing po nameOfMyConstant 
in the LLDB console there is no value, just this error :
error: :3:1: error: use of unresolved identifier 'child1Representation'
child1Representation

Also, if I click on the little (i) icon when my variable is selected in the 
variables list of the debugger, here is what is displayed in the LLDB console :
Printing description of child1Representation:
child1Representation = 

I can't understand at all what is going on ! I am in debug mode and 
optimisations are set to none ! I even moved my source files over to a new 
project, just in case I had done something wrong in the other project settings, 
but that didn't change anything !

Do you have any idea of what is going on ? Is it a Swift/LLDB bug ?
(Xcode Version 8.1 (8B62))

Thank you.

Trevör___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] minimum deployment target

[Zhao Xin via swift-users]

Maybe you should ask this question in
https://forums.developer.apple.com/welcome

Zhaoxin

On Mon, Nov 14, 2016 at 6:26 PM, J.E. Schotsman via swift-users <
swift-users@swift.org> wrote:

> Hello,
>
> I have some code that is used in both a project with minimum deployment
> target 10.9 and a project with minimum deployment target 10.11.
> If I check for availability of API’s on the 10.9 project I get warnings on
> the 10.11 project saying these checks are unnecessary.
> Can I conditionalize this check somehow?
>
> Jan E.
> ___
> 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] minimum deployment target

[J.E. Schotsman via swift-users]

Hello,

I have some code that is used in both a project with minimum deployment target 
10.9 and a project with minimum deployment target 10.11.
If I check for availability of API’s on the 10.9 project I get warnings on the 
10.11 project saying these checks are unnecessary.
Can I conditionalize this check somehow?

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