Re: [swift-users] Removed discussions in doc for Swift 4. Why?

[Erica Sadun via swift-users]

`var` arguments were also removed

-- E


> On Jun 12, 2017, at 12:37 PM, Austin Zheng via swift-users 
>  wrote:
> 
> The currying syntax was removed in Swift 3 (see 
> https://github.com/apple/swift-evolution/blob/master/proposals/0002-remove-currying.md
>  
> ).
>  I'm not aware, though, of any proposal in the pipeline to remove variadic 
> arguments, so it's not clear why the book should have removed discussion 
> about them.
> 
> Austin
> 
> On Mon, Jun 12, 2017 at 11:02 AM, tuuranton--- via swift-users 
> > wrote:
> From
> 
> 
> https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/RevisionHistory.html#//apple_ref/doc/uid/TP40014097-CH40-ID459
>  
> 
> 
> 
> "Removed discussion of variable function arguments and the special syntax for 
> curried functions."
> 
> 
> Why?
> 
> 
> I tried variable function arguments and they seem to work fine in Xcode 9. 
> Didn't try currying yet, however.
> 
> 
> Are these features being phased out?
> 
> 
> 
> ___
> 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

[swift-users] inline best practices?

[Erica Sadun via swift-users]

Any best practices for `@inline(__always)`? When it's short? When has very few 
call sites? When the abstraction aids reading but hinders computation?

Thanks -- E

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

Re: [swift-users] [swift-evolution] for-else syntax

[Erica Sadun via swift-users]

I've taken this over to Swift Users from Swift Evolution.

I think you'd want to handle the exceptional case first, as it provides an 
opportunity for early exit before processing normal behavior. In such case, 
consider using a guard rather than an if:

guard !names.isEmpty else { print("No names"; return }
for name in names { ... }

Flipping the two tests allows you to use an existing if-else without changing 
the language, although there's really nothing that the `else` is adding here:

if names.isEmpty { ... }
else for name in names { ... }

-- E



> On Feb 1, 2017, at 10:31 AM, Saagar Jha via swift-evolution 
>  wrote:
> 
> If you’re fine with a couple extra characters, you can use .isEmpty:
> 
> for name in names {
>   // do your thing
> }
> if names.isEmpty {
>   // do whatever
> }
> 
> It’s a bit more typing, but I feel it makes your intentions more clear.
> 
> Saagar Jha
> 
>> On Feb 1, 2017, at 8:48 AM, Chris Davis via swift-evolution 
>> > wrote:
>> 
>> Hi,
>> 
>> Often when I’m programming I stumble upon this scenario:
>> 
>> I have a list of items that may or may not be empty - if it’s full, I do one 
>> thing, if it’s empty I do something else, my code looks like this:
>> 
>> class Example_1
>> {
>> let names = ["Chris", "John", "Jordan"]
>> 
>> /// Loop over names, if no names, print no names
>> func run()
>> {
>> for name in names
>> {
>> print(name)
>> }
>> 
>> if names.count == 0
>> {
>> print("no names")
>> }
>> }
>> }
>> 
>> let exampleOne = Example_1()
>> exampleOne.run()
>> 
>> However, Personally, I would find it more pleasing to write something like 
>> this:
>> 
>> class Example_2_Proposed
>> {
>> let names:[String] = []
>> 
>> /// Loop over names, if no names, print no names
>> func run()
>> {
>> for name in names
>> {
>> print(name)
>> } else {
>> print("no names")
>> }
>> }
>> }
>> 
>> let exampleTwo = Example_2_Proposed()
>> exampleTwo.run()
>> 
>> The difference here is a “for-else” type syntax where if there were no items 
>> in the array it would simply fall through to the else statement.
>> 
>> What would be the pros/cons of introducing such syntax?
>> 
>> Is there’s a way of doing something similar in swift already?
>> 
>> Thanks
>> 
>> Chris
>> 
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolut...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-users] The value of enums

[Erica Sadun via swift-users]

> On Nov 6, 2016, at 4:07 AM, Tino Heth via swift-users  
> wrote:
> 
> Enums are a fundamental part of Swift, so I guess they won't change much — 
> but I wonder if anyone shares my observations in real-life use…
> 
> Afair, there are three different types of enums:
> - Enums with raw values
> - enums with associated objects
> - Plain enums (no underlying value)
> 
> I use the first type quite often (as a convenient way to create string 
> constants, or for serialization), but see no real value in plain enums (they 
> offer nothing over enums backed with a raw value).
> 
> The second type is special:
> It looks like a really cool concept, and and I started several designs based 
> on them — just to realize later that structs and classes are a better fit.
> My conclusion so far is that enums perform bad as soon as you want to attach 
> additional data or behavior; one or two computed properties are ok, but those 
> switch-statements quickly become a burden.
> There are some options to work around this problem, but I guess I'll just 
> stay away from enums with associated objects by default (with the exception 
> of error-types — imho those can be modeled quite nicely).
> 
> So, that's my current perception, and I'm curious if others had similar 
> experiences — or, even more interesting, completely different observations 
> and elegant solutions based on enums.


Enums:

* Great for umbrella type implementation
* Plain enums: perfect for enumeratable states and defining roles.
* Associated types: I use them mostly for Result type, but also handy for 
things like 
  JSON parsers,  which are Swift's mandated follow-on to "Hello World"
* Enums with raw values: I mostly stick to stringity ones, where there's a 
state or role but
  I want to have easy access to the name as well as the role, and integer ones, 
where I can
  repurpose the number elsewhere
* I really love using enums with switch statements, and compiler guarantees of 
case 
   completeness.

I'd put forth that enum cases should be few, simple, and focused. They should 
not be 
used as flags.  When used well, they should feel obvious and integrate well 
into 
switch statements. 

-- E

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

Re: [swift-users] hashValue of enum cases (was Reducing Array to OptionSet)

[Erica Sadun via swift-users]

It is absolutely an implementation detail and one you should never rely upon! 

— Erica

Sent from my iPhone

> On Nov 4, 2016, at 2:17 PM, Fritz Anderson <fri...@manoverboard.org> wrote:
> 
>> On 3 Nov 2016, at 8:37 PM, Erica Sadun via swift-users 
>> <swift-users@swift.org> wrote:
>> 
>> private enum StringEnum: String { case one, two, three }
>> public init(strings: [String]) {
>> var set = MyOptionSet()
>> strings.flatMap({ StringEnum(rawValue: $0) })
>> .flatMap({ MyOptionSet(rawValue: 1 << $0.hashValue) })
>> .forEach { set.insert($0) }
>> _rawValue = set.rawValue
>> }
> 
> I’m curious about relying on the hash value of an enum case being its 
> declaration-order index. A sage 
> (http://ericasadun.com/2015/07/12/swift-enumerations-or-how-to-annoy-tom/) 
> warns that this  is an implementation detail. I haven’t seen anything saying 
> it is API. Has it been resolved?
> 
> It’s the most plausible implementation, but I’d think code that relies on 
> case order would break silently (likely at widely-separated locations) if a 
> case were inserted or removed. That suggests to me it’s not possible to 
> regularize this behavior.
> 
> Folkloric API (like SEL ↔︎ char* in ObjC) makes me itch.
> 
>   — F
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Reducing Array to OptionSet

[Erica Sadun via swift-users]

How about

func joinOptionSets(_ sets: [OS]) -> OS {
return sets.reduce([] as OS) {
(result, set) in return result.union(set)
}
}

joinOptionSets(sets).rawValue


-- E

> On Nov 3, 2016, at 7:48 PM, Erica Sadun via swift-users 
> <swift-users@swift.org> wrote:
> 
> Like this?
> 
> let sets: [MyOptionSet] = [MyOptionSet(strings: ["one"]), 
> MyOptionSet(strings: ["two"]), MyOptionSet(strings: ["one", "two"])]
> let unioned = sets.reduce(MyOptionSet(rawValue: 0)) {
> (result, set) in return result.union(set)
> }
> unioned.rawValue
> 
> 
>> On Nov 3, 2016, at 7:44 PM, Jon Shier <j...@jonshier.com 
>> <mailto:j...@jonshier.com>> wrote:
>> 
>> Thanks Erica. I’ve been able to transform arrays of strings into arrays of 
>> my OptionSets using an enum approach like you describe. I was looking more 
>> for a generic approach that I could apply to all of the various OptionSets I 
>> have to decode from JSON. I suppose whether it’s from an array of strings or 
>> array of the OptionSet is less important, but getting to the array of the 
>> OptionSet itself is something I can already do. 
>> 
>> 
>> Thanks,
>> 
>> Jon
>> 
>>> On Nov 3, 2016, at 9:37 PM, Erica Sadun <er...@ericasadun.com 
>>> <mailto:er...@ericasadun.com>> wrote:
>>> 
>>> Maybe something like this? Or you could just bitwise || individual sets. Or 
>>> you could use a dictionary to lookup [string: rawValue]. etc.
>>> 
>>> public struct MyOptionSet: OptionSet {
>>> public static let one = MyOptionSet(rawValue: 1 << 0)
>>> public static let two = MyOptionSet(rawValue: 1 << 1)
>>> public static let three = MyOptionSet(rawValue: 1 << 2)
>>> 
>>> public var rawValue: Int { return _rawValue }
>>> public init(rawValue: Int) { self._rawValue = rawValue }
>>> private let _rawValue: Int
>>> 
>>> private enum StringEnum: String { case one, two, three }
>>> public init(strings: [String]) {
>>> var set = MyOptionSet()
>>> strings.flatMap({ StringEnum(rawValue: $0) })
>>> .flatMap({ MyOptionSet(rawValue: 1 << $0.hashValue) })
>>> .forEach { set.insert($0) }
>>> _rawValue = set.rawValue
>>> }
>>> }
>>> 
>>> let stringArray: [String] = ["one", "three"]
>>> let stringOptions = MyOptionSet(strings: stringArray)
>>> stringOptions.rawValue
>>> 
>>>> On Nov 3, 2016, at 7:09 PM, Jon Shier via swift-users 
>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>> 
>>>> Swifters:
>>>>I’m dealing with a JSON API where sets of options are returned as 
>>>> arrays of strings. Representing these as OptionSets seems ideal. I can 
>>>> decode the arrays of strings into an array of individual OptionSet values, 
>>>> but I’ve run into a dead end when trying generically reduce the array of 
>>>> OptionSets to a single OptionSet value. I’ve tried variety of ways of 
>>>> definition a Collection extension, even tried defining a global function, 
>>>> but I can’t seem to use the OptionSet sequence initializer or reduce 
>>>> itself (cannot invoke insert with argument of type (OptionSet) (or T)). 
>>>> Any guidance here? 
>>>>Here’s what I’ve tried:
>>>> 
>>>> extension Collection where Iterator.Element == OptionSet {
>>>> 
>>>>func reduced() -> Iterator.Element {
>>>>return reduce(Iterator.Element()) {
>>>>var newResult = $0
>>>>newResult.insert($1)
>>>>return newResult
>>>>}
>>>>}
>>>> 
>>>> }
>>>> 
>>>> extension Collection where Iterator.Element == OptionSet {
>>>> 
>>>>func reduced() -> T {
>>>>return reduce(T()) {
>>>>var newResult = $0
>>>>newResult.insert($1)
>>>>return newResult
>>>>}
>>>>}
>>>> 
>>>> }
>>>> 
>>>> 
>>>> extension Collection where Iterator.Element == OptionSet {
>>>>func reduced() -> Iterator.Element {
>>>>return Iterator.Element(self)
>>>>}
>>>> }
>>>> 
>>>> func reduced(_ options: [T]) -> T {
>>>>return options.reduce(T()) {
>>>>var newResult = $0
>>>>newResult.insert($1)
>>>> 
>>>>return newResult
>>>>}
>>>> }
>>>> 
>>>> Jon Shier
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>>> <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] Reducing Array to OptionSet

[Erica Sadun via swift-users]

Like this?

let sets: [MyOptionSet] = [MyOptionSet(strings: ["one"]), MyOptionSet(strings: 
["two"]), MyOptionSet(strings: ["one", "two"])]
let unioned = sets.reduce(MyOptionSet(rawValue: 0)) {
(result, set) in return result.union(set)
}
unioned.rawValue


> On Nov 3, 2016, at 7:44 PM, Jon Shier  wrote:
> 
> Thanks Erica. I’ve been able to transform arrays of strings into arrays of my 
> OptionSets using an enum approach like you describe. I was looking more for a 
> generic approach that I could apply to all of the various OptionSets I have 
> to decode from JSON. I suppose whether it’s from an array of strings or array 
> of the OptionSet is less important, but getting to the array of the OptionSet 
> itself is something I can already do. 
> 
> 
> Thanks,
> 
> Jon
> 
>> On Nov 3, 2016, at 9:37 PM, Erica Sadun > > wrote:
>> 
>> Maybe something like this? Or you could just bitwise || individual sets. Or 
>> you could use a dictionary to lookup [string: rawValue]. etc.
>> 
>> public struct MyOptionSet: OptionSet {
>> public static let one = MyOptionSet(rawValue: 1 << 0)
>> public static let two = MyOptionSet(rawValue: 1 << 1)
>> public static let three = MyOptionSet(rawValue: 1 << 2)
>> 
>> public var rawValue: Int { return _rawValue }
>> public init(rawValue: Int) { self._rawValue = rawValue }
>> private let _rawValue: Int
>> 
>> private enum StringEnum: String { case one, two, three }
>> public init(strings: [String]) {
>> var set = MyOptionSet()
>> strings.flatMap({ StringEnum(rawValue: $0) })
>> .flatMap({ MyOptionSet(rawValue: 1 << $0.hashValue) })
>> .forEach { set.insert($0) }
>> _rawValue = set.rawValue
>> }
>> }
>> 
>> let stringArray: [String] = ["one", "three"]
>> let stringOptions = MyOptionSet(strings: stringArray)
>> stringOptions.rawValue
>> 
>>> On Nov 3, 2016, at 7:09 PM, Jon Shier via swift-users 
>>> > wrote:
>>> 
>>> Swifters:
>>> I’m dealing with a JSON API where sets of options are returned as 
>>> arrays of strings. Representing these as OptionSets seems ideal. I can 
>>> decode the arrays of strings into an array of individual OptionSet values, 
>>> but I’ve run into a dead end when trying generically reduce the array of 
>>> OptionSets to a single OptionSet value. I’ve tried variety of ways of 
>>> definition a Collection extension, even tried defining a global function, 
>>> but I can’t seem to use the OptionSet sequence initializer or reduce itself 
>>> (cannot invoke insert with argument of type (OptionSet) (or T)). Any 
>>> guidance here? 
>>> Here’s what I’ve tried:
>>> 
>>> extension Collection where Iterator.Element == OptionSet {
>>> 
>>>func reduced() -> Iterator.Element {
>>>return reduce(Iterator.Element()) {
>>>var newResult = $0
>>>newResult.insert($1)
>>>return newResult
>>>}
>>>}
>>> 
>>> }
>>> 
>>> extension Collection where Iterator.Element == OptionSet {
>>> 
>>>func reduced() -> T {
>>>return reduce(T()) {
>>>var newResult = $0
>>>newResult.insert($1)
>>>return newResult
>>>}
>>>}
>>> 
>>> }
>>> 
>>> 
>>> extension Collection where Iterator.Element == OptionSet {
>>>func reduced() -> Iterator.Element {
>>>return Iterator.Element(self)
>>>}
>>> }
>>> 
>>> func reduced(_ options: [T]) -> T {
>>>return options.reduce(T()) {
>>>var newResult = $0
>>>newResult.insert($1)
>>> 
>>>return newResult
>>>}
>>> }
>>> 
>>> Jon Shier
>>> ___
>>> 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] Reducing Array to OptionSet

[Erica Sadun via swift-users]

Maybe something like this? Or you could just bitwise || individual sets. Or you 
could use a dictionary to lookup [string: rawValue]. etc.

public struct MyOptionSet: OptionSet {
public static let one = MyOptionSet(rawValue: 1 << 0)
public static let two = MyOptionSet(rawValue: 1 << 1)
public static let three = MyOptionSet(rawValue: 1 << 2)

public var rawValue: Int { return _rawValue }
public init(rawValue: Int) { self._rawValue = rawValue }
private let _rawValue: Int

private enum StringEnum: String { case one, two, three }
public init(strings: [String]) {
var set = MyOptionSet()
strings.flatMap({ StringEnum(rawValue: $0) })
.flatMap({ MyOptionSet(rawValue: 1 << $0.hashValue) })
.forEach { set.insert($0) }
_rawValue = set.rawValue
}
}

let stringArray: [String] = ["one", "three"]
let stringOptions = MyOptionSet(strings: stringArray)
stringOptions.rawValue

> On Nov 3, 2016, at 7:09 PM, Jon Shier via swift-users  
> wrote:
> 
> Swifters:
>   I’m dealing with a JSON API where sets of options are returned as 
> arrays of strings. Representing these as OptionSets seems ideal. I can decode 
> the arrays of strings into an array of individual OptionSet values, but I’ve 
> run into a dead end when trying generically reduce the array of OptionSets to 
> a single OptionSet value. I’ve tried variety of ways of definition a 
> Collection extension, even tried defining a global function, but I can’t seem 
> to use the OptionSet sequence initializer or reduce itself (cannot invoke 
> insert with argument of type (OptionSet) (or T)). Any guidance here? 
>   Here’s what I’ve tried:
> 
> extension Collection where Iterator.Element == OptionSet {
> 
>func reduced() -> Iterator.Element {
>return reduce(Iterator.Element()) {
>var newResult = $0
>newResult.insert($1)
>return newResult
>}
>}
> 
> }
> 
> extension Collection where Iterator.Element == OptionSet {
> 
>func reduced() -> T {
>return reduce(T()) {
>var newResult = $0
>newResult.insert($1)
>return newResult
>}
>}
> 
> }
> 
> 
> extension Collection where Iterator.Element == OptionSet {
>func reduced() -> Iterator.Element {
>return Iterator.Element(self)
>}
> }
> 
> func reduced(_ options: [T]) -> T {
>return options.reduce(T()) {
>var newResult = $0
>newResult.insert($1)
> 
>return newResult
>}
> }
> 
> Jon Shier
> ___
> 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] Monorepo workflow using SPM

[Erica Sadun via swift-users]

I want less of a monorepo than an ability to build a group of orthogonal 
elements into a single repo so I don't have to create a separate repo for every 
single Swift library I build, especially when there are logical relationships 
between subfolders and partial incorporation into builds  For example, I'm 
messing with core graphics geometry right now. I have basic types & extensions, 
some experimental stuff, and other misc things for (for example) doing 
playground visualization support. Rather than over-conditionalize my code, I'd 
rather conditionalize the package, so that everything pulls, compiles, and 
works fine on, say, a macOS build but bits that don't belong (iOS playground 
visualization support) can be omitted from a specific configuration *for* 
*that* *repo* instead of me having to make really ugly code conditions in files 
which are intended specifically for known targets and may be excluded from 
package builds because of their intended targets.

-- E


> On Nov 3, 2016, at 2:31 PM, Ankit Agarwal via swift-users 
>  wrote:
> 
> +swift-build-dev
> 
> Not right now but we're considering adding support for multiple packages in a 
> repository. It would be good if you can explain your 
> requirements/features/flow are you looking for.
> 
> On Friday 4 November 2016, Georgios Moschovitis via swift-users 
> > wrote:
> The Swift Package Manager is a great addition to the Swift programmer's 
> toolbelt and in general I like the integration with Git.
> 
> However, since SPM promotes a separate Git repo per package and actually 
> leverages Git tags to resolve dependency versions, I am wondering if it's 
> possible to use the popular(?) 'monorepo' workflow with SPM. 
> 
> thanks,
> -g.
> 
> 
> -- 
> Ankit
> 
> 
> ___
> 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] Swift Playgrounds Not Included with iiOS 10.0.1 GM

[Erica Sadun via swift-users]

And for anyone still wondering -- my iPad hadn't started but aborted the 
upgrade. I was still running the beta not the GM

-- E


> On Sep 8, 2016, at 6:16 PM, Jordan Rose via swift-users 
> <swift-users@swift.org> wrote:
> 
> The Swift Playgrounds app is not part of the Swift Open Source project, but 
> just to clear things up: the app will be in the App Store when it goes live, 
> not shipped with the OS (as mentioned in 
> http://www.apple.com/swift/playgrounds/ 
> <http://www.apple.com/swift/playgrounds/>). More detail than that isn't 
> really something we can talk about on this list.
> 
> Jordan
> 
> 
>> On Sep 8, 2016, at 17:09, Michael Sheaver via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> My iPad has. 81 GB free, so that wasn't the issue. Like Zhao, I used the OTA 
>> for this upgrade. I could test it by installing the restore image, but at 
>> this point I am not sure it is worth any more effort. What do you think?
>> 
>>> On Sep 8, 2016, at 7:53 PM, Zhao Xin <owe...@gmail.com 
>>> <mailto:owe...@gmail.com>> wrote:
>>> 
>>> It is not on mine after upgrading to GM through OTA. Mine free space is 
>>> 9.35GB.
>>> 
>>> I think it can be easily explained. It is not a system app, it appeared in 
>>> beta just because it is easily for us to test. It will appear in App Store 
>>> when iOS 10 officially released.
>>> 
>>> Zhaoxin
>>> 
>>> On Fri, Sep 9, 2016 at 7:25 AM, Erica Sadun via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>> It is still on my iPad.
>>> 
>>> As far as I can tell (going by Twitter replies), if you had sufficient 
>>> space for the upgrade (I had about 3.5 gb), it was not removed.
>>> 
>>> I recommend filing a bug report at bugreport.apple.com 
>>> <http://bugreport.apple.com/>
>>> 
>>> -- E
>>> 
>>> 
>>>> On Sep 8, 2016, at 3:23 PM, Michael Sheaver via swift-users 
>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>> 
>>>> This is just a heads-up for all who might be using/enjoying/playing with 
>>>> Swift Playgrounds on the iPad; it has apparently been removed from the GM 
>>>> that was released yesterday. There are a couple posts about it in the 
>>>> Apple forums, but no definitive answers have been posted as yet. I 
>>>> searched in the App Store, and it isn't there yet either.
>>>> 
>>>> Michael Sheaver
>>>> 
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>>> 
>>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto: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] Swift Playgrounds Not Included with iiOS 10.0.1 GM

[Erica Sadun via swift-users]

It is still on my iPad.

As far as I can tell (going by Twitter replies), if you had sufficient space 
for the upgrade (I had about 3.5 gb), it was not removed.

I recommend filing a bug report at bugreport.apple.com 


-- E


> On Sep 8, 2016, at 3:23 PM, Michael Sheaver via swift-users 
>  wrote:
> 
> This is just a heads-up for all who might be using/enjoying/playing with 
> Swift Playgrounds on the iPad; it has apparently been removed from the GM 
> that was released yesterday. There are a couple posts about it in the Apple 
> forums, but no definitive answers have been posted as yet. I searched in the 
> App Store, and it isn't there yet either.
> 
> Michael Sheaver
> 
> ___
> 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] Cleaner way than if let initialization?

[Erica Sadun via swift-users]

> On Aug 4, 2016, at 1:41 PM, Tim Vermeulen via swift-users 
>  wrote:
> 
> You want `flatMap`:
> 
> let dobString = dob.flatMap(serverDateFormatter.stringFromDate)
> 
> Or if you want `dobString` to be non-optional:
> 
> let dobString = dob.flatMap(serverDateFormatter.stringFromDate) ?? “"

You can just use map here too, right?

let dobString2: String = dob.map(serverDateFormatter.string) ?? ""

I was a little surprised that this didn't need the rest of the selector 
signature but that's because parameter stripping and type matching, isn't it?

> 
>> Currently I do stuff like this:
>> 
>> letdobString:String
>> ifletdob = dob {
>> dobString =serverDateFormatter.stringFromDate(dob)
>> }
>> else{
>> dobString =""
>> }
>> 
>> Is there a better, more idiomatic, way to do this sort of thing?
>> 
>> 
>> 
>> 
> ___
> 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] Cleaner way than if let initialization?

[Erica Sadun via swift-users]

> On Aug 4, 2016, at 11:32 AM, Daniel Tartaglia via swift-users 
>  wrote:
> 
> Currently I do stuff like this:
> 
> let dobString: String
> if let dob = dob {
>   dobString = serverDateFormatter.stringFromDate(dob)
> }
> else {
>   dobString = ""
> }
> 
> Is there a better, more idiomatic, way to do this sort of thing?

So if I understand this correctly `dob` is an optional date, and `dobString` is 
a non-optional String. Right? 

If that's what you're dealing with, then you  basically to do a double 
conditional: dob is optional, and stringFromDate returns optional, right? I'd 
do it like this:

let dobString: String = {
guard
let dob = dob,
let dobString = serverDateFormatter.stringFromDate(dob)
else { return "" }
return dobString
}()

But if serverDateFormatter is actually a NSDateFormatter instance, which does 
not return optionals, then you'd want to go with:

let dobString: String = {
guard let dob = dob else { return "" }
return serverDateFormatter.string(from:dob)
}()

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

Re: [swift-users] Toolchain 07/29

[Erica Sadun via swift-users]

7/25 does not work for me. -- E

> On Aug 1, 2016, at 10:51 AM, Charles Lane  wrote:
> 
> The 7/25 snapshot seems to work. That was before AnyObject was changed to Any.
> 
> Regards,
> Charles Lane
> 
> 
>> On Aug 1, 2016, at 11:17 AM, Erica Sadun  wrote:
>> 
>> What is the most recent snapshot that will actually work and compile code? 
>> 7/29 and 7/28 both fail for me.
>> 
>> Thanks!
>> 
>> -- Erica
>> 
>> 
>>> On Jul 31, 2016, at 4:19 PM, Charles Lane via swift-users 
>>>  wrote:
>>> 
>>> Bug report SR-2234 has been filed.
>>> 
>>> Thanks
>>> 
>>> 
 On Jul 31, 2016, at 4:38 PM, Mark Lacey  wrote:
 
 Can you please open a bug for this at bugs.swift.org?
 
 Mark
 
> On Jul 31, 2016, at 13:07, Charles Lane via swift-users 
>  wrote:
> 
> With Xcode Beta 3 and toolchain 07/29 the following line will cause a 
> segmentation fault 11:
> 
> func imagePickerController(_ picker: UIImagePickerController, 
> didFinishPickingMediaWithInfo info: [String: Any]) {
>…
>…
>dismiss(animated: true)
> }
> 
> 
> You have to leave this: [String: Any] as [String: AnyObject] and mark the 
> func as @nonobc to stop the warning and stop the segmentation fault.
> 
> 
> ___
> 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] Toolchain 07/29

[Erica Sadun via swift-users]

What is the most recent snapshot that will actually work and compile code? 7/29 
and 7/28 both fail for me.

Thanks!

-- Erica


> On Jul 31, 2016, at 4:19 PM, Charles Lane via swift-users 
>  wrote:
> 
> Bug report SR-2234 has been filed.
> 
> Thanks
> 
> 
>> On Jul 31, 2016, at 4:38 PM, Mark Lacey  wrote:
>> 
>> Can you please open a bug for this at bugs.swift.org?
>> 
>> Mark
>> 
>>> On Jul 31, 2016, at 13:07, Charles Lane via swift-users 
>>>  wrote:
>>> 
>>> With Xcode Beta 3 and toolchain 07/29 the following line will cause a 
>>> segmentation fault 11:
>>> 
>>> func imagePickerController(_ picker: UIImagePickerController, 
>>> didFinishPickingMediaWithInfo info: [String: Any]) {
>>>  …
>>>  …
>>>  dismiss(animated: true)
>>>  }
>>> 
>>> 
>>> You have to leave this: [String: Any] as [String: AnyObject] and mark the 
>>> func as @nonobc to stop the warning and stop the segmentation fault.
>>> 
>>> 
>>> ___
>>> 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] [swift-evolution] Multi dimensional - iterator, Iterator2D, Iterator3D

[Erica Sadun via swift-users]

I'm replying on Swift-Users and bcc'ing in Swift-Evolution to comply with the 
core team's request to focus SE on the current mission statement. 

At some point soon, Russ Bishop's PR https://github.com/apple/swift/pull/3600 
 will be incorporated into Swift 3. 
This PR adds `prefix(while:)` and `drop(while:)` to finish implementing 
SE-0045.  Once that's done, you can  combine `sequence(first:, next:)` and 
`prefix(while:)` to into a single function `sequence(first:, next:, while:)` 
like this:

public func sequence(first: T, next: (T) -> T?, while test: (T) -> Bool) -> 
UnfoldSequence> {
return sequence(first: first, next: next).prefix(while: test)
}

The combined sequence/prefix call allows you to create loops like this:

for outerIndex in sequence(first: 1, next: { $0 * 2 }, while: { $0 <= 64 }) {
for innerIndex in sequence(first: 1, next: { $0 * 2 }, while: { $0 <= 64 }) 
{
print(outerIndex, innerIndex)
}
}

These loops can be nested. break and continue work.  You can use tuples for 
multiple arguments. While I'd like to see a combined form adopted into Swift 4b 
(the deferred "sugar"), it isn't a high priority.

-- E


> On Jul 31, 2016, at 7:18 AM, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> 
>> On 31.07.2016, at 04:28, jaden.gel...@gmail.com 
>>  wrote:
>> 
>> What benefit do Iterator2D and Iterator3D provide that nesting does not?
> Hi Jaden,
> well, simply because of hiding/enclosing repetitive functionality
> like with every other programming element is convenient,
> prevents errors and from writing the same over and over again.
> That is why there are functions.
> but you already know that, of course.
> Kind Regards
> TedvG
> 
>> 
>> On Jul 30, 2016, at 1:48 PM, Ted F.A. van Gaalen via swift-evolution 
>> > wrote:
>> 
>>> Hi Chris,
>>> 
>>> thanks for the tip about Hirundo app!
>>> 
>>> A positive side-effect of removing the classical for;; loop
>>>  (yes, it’s me saying this :o)  is that it forces me to find
>>> a good and generic equivalent for it, 
>>> making the conversion of my for;;s to 3.0 easier.
>>> which is *not* based on collections or sequences and
>>> does not rely on deeper calls to Sequence etc.
>>> 
>>> so, I’ve made the functions [iterator, iterator2D, iterator3D]  (hereunder)
>>> wich btw clearly demonstrate the power and flexibility of Swift. 
>>> 
>>> Very straightforward, and efficient (i assume) just like the classical 
>>> for;; loop.  
>>> It works quite well in my sources.
>>> 
>>> As a spin-off,  I’ve extended these to iterators for matrices 2D and cubes? 
>>> 3D...
>>> 
>>> Question: 
>>> Perhaps implementing “multi dimensional iterator functions
>>> in Swift might  be a good idea. so that is no longer necessary to 
>>> nest/nest/nest iterators. 
>>> 
>>> Met vriendelijke groeten, sorry for my “intensity” in discussing the 
>>> classical for;; 
>>> I'll have to rethink this for;; again..  
>>> Thanks, Ted.
>>> 
>>> Any remarks ( all ), suggestions about the code hereunder:  ? 
>>> 
>>> protocol NumericType
>>> {
>>> func +(lhs: Self, rhs: Self) -> Self
>>> func -(lhs: Self, rhs: Self) -> Self
>>> func *(lhs: Self, rhs: Self) -> Self
>>> func /(lhs: Self, rhs: Self) -> Self
>>> func %(lhs: Self, rhs: Self) -> Self
>>> }
>>> 
>>> extension Double : NumericType { }
>>> extension Float  : NumericType { }
>>> extension CGFloat: NumericType { }
>>> extension Int: NumericType { }
>>> extension Int8   : NumericType { }
>>> extension Int16  : NumericType { }
>>> extension Int32  : NumericType { }
>>> extension Int64  : NumericType { }
>>> extension UInt   : NumericType { }
>>> extension UInt8  : NumericType { }
>>> extension UInt16 : NumericType { }
>>> extension UInt32 : NumericType { }
>>> extension UInt64 : NumericType { }
>>> 
>>> 
>>> /// Simple iterator with generic parameters, with just a few lines of code.
>>> /// for most numeric types (see above)
>>> /// Usage Example:
>>> ///
>>> ///   iterate(xmax, { $0 > xmin}, -xstep,
>>> ///{x in
>>> ///print("x = \(x)")
>>> ///return true  // returning false acts like a break
>>> /// } )
>>> ///
>>> ///  -Parameter vstart: Initial value
>>> ///  -Parameter step:The iteration stepping value.
>>> ///  -Parameter test:A block with iteration test. e.g. {$0 > 10}
>>> ///
>>> ///  -Parameter block:   A block to be executed with each step.
>>> ///   The block must include a return true (acts like "continue")
>>> ///   or false (acts like "break")
>>> ///  -Please Note: 
>>> ///  There is minor precision loss ca: 1/1000 ... 1/500 
>>> ///  when iterating with floating point numbers.
>>> ///  However, in most cases this can be safely ignored.
>>> ///  made by ted van gaalen.
>>> 
>>> 
>>> func iterate (
>>>  

Re: [swift-users] Simplify chained calls

[Erica Sadun via swift-users]

> 
> On Jun 28, 2016, at 8:18 PM, Dan Loewenherz via swift-users 
>  wrote:
> 
> I’m not sure if you wanted to stick with the pure functional approach, but 
> here’s an alternative that uses Range to take care of most of the work.
> 
> func selectionSort(_ array: [Int]) -> [Int] {
> guard let minValue = array.min(), let index = array.index(of: minValue) 
> else {
> return []
> }
> 
> let ranges = [0.. return [minValue] + selectionSort(ranges.flatMap { array[$0] })
> }
> 

Most everyone is doing two passes, one to get the minimum value, another to get 
its index.
I aesthetically prefer using enumerate to do both at once.

-- E

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

Re: [swift-users] expression too complex

[Erica Sadun via swift-users]

func foo () -> Bool {
return Double((pt.x - p0.x) * (p1.y - p0.y) - (pt.y - p0.y) * (p1.x - 
p0.x)) < 0.0
}

See if that works and then file a bug report?

-- E

> On Jun 16, 2016, at 2:59 PM, Dave Reed via swift-users 
>  wrote:
> 
> 
> Joe, 
> 
> I had an expression that worked fine with Swift2.2 but Swift3 (Xcode 8 
> version) complains it's too complex:
> 
> The variables are of type CGPoint and the function returns a Bool.
> 
>return (pt.x - p0.x) * (p1.y - p0.y) - (pt.y - p0.y) * (p1.x - p0.x) < 0.0
> 
> Thanks,
> Dave
> 
> 
>> On Jun 6, 2016, at 6:15 PM, Joe Groff via swift-users 
>>  wrote:
>> 
>> 
>>> On Jun 6, 2016, at 3:13 PM, Saagar Jha  wrote:
>>> 
>>> I’ve seen that this tends to happen with operators that are really 
>>> overloaded-stuff like +, *, etc. The compiler seems to take longer to 
>>> figure out which function to use.
>> 
>> Yeah. The type checker has gotten better about making these situations with 
>> lots of overload operators tractable in common cases. Over the remaining 
>> course of Swift 3, we're also looking to rearchitect the standard library so 
>> that there are fewer generic global operator overloads, moving the 
>> polymorphism into protocol methods instead, which should further reduce the 
>> burden on the type checker.
>> 
>> -Joe
>> 
>>> On Mon, Jun 6, 2016 at 3:09 PM Joe Groff via swift-users 
>>>  wrote:
>>> 
 On Jun 6, 2016, at 3:06 PM, G B via swift-users  
 wrote:
 
 Is progress being made on the type checker to get the compiler to stop 
 whinging about the complexity of expressions?
>>> 
>>> Yes, a lot of cases work much better in Swift 3. You might give these a try 
>>> in a nightly build. Please file a bug if you continue to see this in Swift 
>>> 3 though.
>>> 
>>> -Joe
>>> 
 
 I can’t really trim down the full project to isolate a good test case, but 
 I’m getting a compiler error on this line of code:
 let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
 
 
 Interestingly, this line compiled fine (everything is the same except the 
 last list element is moved to the front):
 let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])
 
 
 
 The initializer that this code is embedded in is this:
 public init(axis:T.Vector3Type, angle a:T){
  let s=sin(a/2.0)
  let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
  let l=v.length()
  self.init(v/l)
 }
 
 I’m running this in a playground, I don’t know if that makes a difference.
 
 I’m willing to wait a little longer for the complier to do its job if it 
 means I don’t have to break my code down to one operation per line.
 ___
 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
>>> -- 
>>> -Saagar Jha
>> 
>> ___
>> 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] expression too complex

[Erica Sadun via swift-users]

I've seen this happen specifically in collections.

There was one only yesterday that I was helping out with:

http://i.imgur.com/tKh9On6.jpg 

Try doing this with all the String:Closure pairs in the original declaration.

-- E




> On Jun 6, 2016, at 4:15 PM, Joe Groff via swift-users  
> wrote:
> 
> 
>> On Jun 6, 2016, at 3:13 PM, Saagar Jha  wrote:
>> 
>> I’ve seen that this tends to happen with operators that are really 
>> overloaded-stuff like +, *, etc. The compiler seems to take longer to figure 
>> out which function to use.
> 
> Yeah. The type checker has gotten better about making these situations with 
> lots of overload operators tractable in common cases. Over the remaining 
> course of Swift 3, we're also looking to rearchitect the standard library so 
> that there are fewer generic global operator overloads, moving the 
> polymorphism into protocol methods instead, which should further reduce the 
> burden on the type checker.
> 
> -Joe
> 
>> On Mon, Jun 6, 2016 at 3:09 PM Joe Groff via swift-users 
>>  wrote:
>> 
>>> On Jun 6, 2016, at 3:06 PM, G B via swift-users  
>>> wrote:
>>> 
>>> Is progress being made on the type checker to get the compiler to stop 
>>> whinging about the complexity of expressions?
>> 
>> Yes, a lot of cases work much better in Swift 3. You might give these a try 
>> in a nightly build. Please file a bug if you continue to see this in Swift 3 
>> though.
>> 
>> -Joe
>> 
>>> 
>>> I can’t really trim down the full project to isolate a good test case, but 
>>> I’m getting a compiler error on this line of code:
>>> let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
>>> 
>>> 
>>> Interestingly, this line compiled fine (everything is the same except the 
>>> last list element is moved to the front):
>>> let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])
>>> 
>>> 
>>> 
>>> The initializer that this code is embedded in is this:
>>> public init(axis:T.Vector3Type, angle a:T){
>>>   let s=sin(a/2.0)
>>>   let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
>>>   let l=v.length()
>>>   self.init(v/l)
>>> }
>>> 
>>> I’m running this in a playground, I don’t know if that makes a difference.
>>> 
>>> I’m willing to wait a little longer for the complier to do its job if it 
>>> means I don’t have to break my code down to one operation per line.
>>> ___
>>> 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
>> -- 
>> -Saagar Jha
> 
> ___
> 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] String Comparisons in Swift

[Erica Sadun via swift-users]

> On Jun 2, 2016, at 1:07 PM, John Myers via swift-users 
>  wrote:
> 
> I've had some difficulty comparing string variables to string constants with 
> ==.  I believe it's always after using a readLine().  Does Swift require a 
> .equals() or a .compareTo(), as other c like languages, or are there 
> invisible characters in my string because of the readLine() which I need to 
> strip out?
> Thanks!

Have you compared characters.count on the two strings? Could you be pulling in 
\r\n?

-- E


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

Re: [swift-users] Wrapping function declarations in #if swift()

[Erica Sadun via swift-users]

> On May 12, 2016, at 11:38 PM, Tyler Fleming Cloutier via swift-users 
>  wrote:
> 
> Hello everyone,
> 
> It does seem like it is currently possible to wrap just the function 
> declaration in an #if swift() directive like so:
> 
> #if swift(>=3.0)
> public func add(filter filterName: String, path: String) {
> #else // ERROR Expected ‘}’ at end of brace statement
> public func addFilter(filterName: String, path: String) {
> #endif
> 
> Is it possible I’m missing how to do this? This is particularly painful in 
> Swift 3 given the change to move have labels on the first function parameter 
> by default. As far as I can see it means that I am required to wrap the 
> entire function body even if nothing else is incompatible with Swift 3.

Alternatively, you could move the function body out to a separate closure and 
call it from differentiated 3 and 2.2 signatures.

I may have written a blog post about this this morning.

-- Erica


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

Re: [swift-users] Can't declare variable with same name as func called to assign its initial value

[Erica Sadun via swift-users]

> On May 12, 2016, at 1:07 PM, Evan Maloney via swift-users 
>  wrote:
> 
> Adopting the newer Swift style of preferring first parameter labels, I wrote 
> a function:
> 
>func sale(options options: DeepLinkOptions)
>throws
>-> Sale
>{
>// ...implementation...
>}
> 
> I then tried calling it elsewhere, and setting the result to a variable named 
> 'sale', which is coincidentally the same name as the function above:
> 
>let sale = try sale(options: options)
> 
> This line won't compile, failing with the following error and a caret 
> pointing at the second use of 'sale':
> 
>variable used within its own initial value
> 
> In the past, I would've named the function above according to Objective-C 
> conventions, and it might've ended up with a name like 'saleWithOptions'; 
> there'd be no clash. However, with the more terse Swift 3.0 style, we'll 
> probably end up with more situations like mine.
> 
> Is this (should this be?) considered a bug or compiler limitation? Should I 
> file a JIRA? There doesn't seem to be anything for this on bugs.swift.org yet.

I'm going to go with the classic answer: 
http://www.urbandictionary.com/define.php?term=Henny+Youngman+problem

consider: let sale2 = sale
you could then run sale2(options: options)

So why should let sale = sale be any different?___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Initializing a UIColor

[Erica Sadun via swift-users]

> 
>> On May 11, 2016, at 9:57 AM, Dennis Weissmann > > wrote:
>> 
>> Huh! There’s a new overload for that initializer:
>> 
>> 
>> 
>> The one that takes CGFloats is the one that was there before, but the one 
>> taking Floats is new!
>> 
>> You can work around like this:
>> 
>> let color = UIColor(red: CGFloat(0.892), green: CGFloat(0.609), blue: 
>> CGFloat(0.048),  alpha: CGFloat(1.000))
>> or
>> let color = UIColor(red: Float(0.892), green: Float(0.609), blue: 
>> Float(0.048),  alpha: Float(1.000))
>> 
>> - Dennis


Wow, that's a ridiculous situation to have.  Who uses Float with iOS/tvOS 
anyway? 

I created a workaround, but I hate it:

extension Double {
var cg: CGFloat { return CGFloat(self) }
}

class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let c = UIColor(red: 0.5.cg, green: 0.5, blue: 0.5, alpha: 0.5)
}
}

-- E

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

Re: [swift-users] Guarding against an empty sequence

[Erica Sadun via swift-users]

I know this is completely not answering your question, but why wouldn't an 
empty sequence return true? There is no element in an empty sequence that does 
not satisfy the predicate.

As for guarding against an empty sequence, you can create a buffered sequence 
type with 1-lookahead. Off the top of my head, n o guarantees for correctness:

public struct BufferedSequence:GeneratorType, SequenceType 
{

internal var _base: Base
internal var _generator: Base.Generator
public var bufferedElement: Base.Generator.Element?

public init(_ base: Base) {
_base = base
_generator = base.generate()
bufferedElement = _generator.next()
}

public mutating func next() -> Base.Generator.Element? {
defer {
if bufferedElement != nil {
bufferedElement = _generator.next()
}
}
return bufferedElement
}

public func isEmpty() -> Bool {
return bufferedElement == nil
}
}

-- E


> On May 8, 2016, at 8:16 PM, Adriano Ferreira via swift-users 
>  wrote:
> 
> Hi everyone!
> 
> I’m working on the following method:
> 
> extension SequenceType {
> 
> /// Check if `predicate` is true for all elements of `self`
> ///
> /// - Parameter predicate: The predicate called on each element of `self`
> ///
> /// - Returns: True iff every element in `self` satisfies `predicate`, 
> false otherwise
> 
> @warn_unused_result
> func all(@noescape where predicate: Generator.Element throws -> Bool) 
> rethrows -> Bool {
> for element in self where try !predicate(element) {
> return false
> }
> 
> return true
> }
> }
> 
> However, when the sequence is empty the method returns true, which is not the 
> desired behaviour.
> 
> let a = [Int]()
> let b = a.all(where: { $0 > 7 })
> XCTAssertFalse(b)   // This fails, cause there’s no guard against an empty 
> sequence
> 
> Does anyone know how to guard against an empty sequence?
> 
> I’m using Xcode 7.3.1 and Swift 2.2.
> 
> Best,
> 
> — A
> ___
> 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] Trying to learn swift 3 renamification (as mattn calls it!)

[Erica Sadun via swift-users]

> On Apr 21, 2016, at 2:05 PM, Ryan Lovelett <swift-...@ryan.lovelett.me> wrote:
> 
> On Thu, Apr 21, 2016, at 03:50 PM, Erica Sadun via swift-users wrote:
>>  
>>> On Apr 21, 2016, at 12:57 PM, Charles Lane via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>  
>>> While rebuilding some apps using the new development trunk build, I figured 
>>> out the naming changes to just about everything but this:
>>>  
>>> let string = "Here is a string"
>>>  
>>> string.drawWithRect(CGRect(x: 10, y: 10, width: 200, height: 200), options: 
>>> .usesLineFragmentOrigin, attributes: attrs, context: nil)
>>>  
>>> Can someone tell me what the ‘string.drawWithRect changed to?
>> 
>>  
>> @available(iOS 7.0, *)
>> public func draw(with rect: CGRect, options: NSStringDrawingOptions = [], 
>> attributes: [String : AnyObject]? = [:], context: NSStringDrawingContext?)
>  
> Erica would you mind discussing/explaining how you went about figuring out 
> what this function signature was? It looked like you copied/pasted it from 
> Xcode (based on the styling). Did you just know the function and go to its 
> source?
>  

I clicked through to the UIKit module, from there to NSString extensions, and 
then looked for draw.

-- E

>>  
>>  
>> Not personally a fan since "with" makes no sense for a geometric boundary 
>> unlike in: or inRect:.
>>  
>> -- E
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> <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] ?? operator question

[Erica Sadun via swift-users]

> On Apr 18, 2016, at 7:23 AM, zh ao via swift-users  
> wrote:
> 
> I do think there is something wrong here.
> 
> // Xcode 7.3.1, Swift 2.2
> 
> let t1: Int? = 2 // struct Int?
> let y = t1 ?? "abcdf" // error
> let x = t1 ?? NSFont(name: "", size: 0) // x: NSObject?
> 
> for x, how could it be NSObject?, as t1 is a struct?
> 
> zhaoxin

My guess would be NSNumber.

Strings can bridge to NSString (struct to class), enums of ErrorType to NSError 
(enum to class), etc.

-- E

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

Re: [swift-users] [swift-evolution] What about a VBA style with Statement?

[Erica Sadun via swift-users]

> On Apr 13, 2016, at 9:26 AM, Sean Heber  wrote:
> 
>> On Apr 13, 2016, at 10:08 AM, Erica Sadun  wrote:
>> 
>> 
>>> On Apr 13, 2016, at 8:25 AM, Sean Heber via swift-evolution 
>>>  wrote:
>>> 
>>> This pair works pretty well, too, if you don’t mind free functions:
>>> 
>>> func with(inout this: T, @noescape using: inout T->Void) { using() }
>>> func with(this: T, @noescape using: T->Void) { using(this) }
>>> 
>>> It works either with classes or mutable structs if you call it correctly 
>>> and the type doesn’t matter.
>>> 
>>> l8r
>>> Sean
>> 
>> My current version is this:
>> 
>> func with(item: T, @noescape update: (inout T) -> Void) -> T {
>>var this = item; update(); return this
>> }
>> 
>> Used, for example:
>> 
>> struct Foo { var (a, b, c) = ("a", "b", "c") }
>> class Bar: DefaultReflectable { var (a, b, c) = ("a", "b", 2.5) }
>> var f = with(Foo()) { $0.a = "X" }
>> var b = with(Bar()) { $0.a = "X" }
>> print(f) // Foo(a: "X", b: "b", c: "c")
>> print(b) // Bar(a=X, b=b, c=c)
>> 
>> Is there an advantage to having a pair of functions?
> 
> I don’t know if it’s a huge advantage or not, but with warnings on unused 
> results, using a with() that has a return with a class instance would mean 
> you’d have to discard the return result explicitly or pointlessly reassign 
> the results to your instance (thus meaning not using a let) just to avoid the 
> warning. If you annotated the with() to allow discarding the result, then 
> it’d be error-prone for structs. It seemed “safer” to me to have a pair.
> 
> l8r
> Sean
> 

If you want to call

>> let f = with(Foo()) { $0.a = "X" }
>> let b = with(Bar()) { $0.a = "X" }

with constant assignment and an initializer, I'm not sure how yours would work. 
Could they?

-- E, trying right now in the playground

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

Re: [swift-users] [swift-evolution] Requesting default values for Cocoa/Cocoa Touch APIs

[Erica Sadun via swift-users]

> On Apr 11, 2016, at 4:32 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Apr 11 2016, Russ Bishop  wrote:
> 
>> Wouldn’t this be the responsibility of UIKit/AppKit teams to provide 
>> extensions
>> that pass the default values?
> 
> Yup.  Please file radars against those components.
> 

Switching to Swift-Users:  Daniel Steinberg and I want to expand SE-0005-like 
defaults to common Cocoa and Cocoa-Touch patterns. This discussion really 
doesn't fall under Swift-Evolution so I've cc'ed in Swift-Users for further 
discussion (Please drop Swift-Evolution in your replies)

We've set up a gist: 
https://gist.github.com/erica/3987ec54b8f4a580ae5fc18f4e9e7ca5 
 with our 
preliminary suggestions.

Thanks in advance for any feedback,

-- Erica

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

Re: [swift-users] Sampling collections

[Erica Sadun via swift-users]

> On Apr 10, 2016, at 2:39 PM, Milos Rankovic  
> wrote:
> 
>> On 10 Apr 2016, at 21:23, Erica Sadun > > wrote:
>> 
>> I do not think it's the role of a core language to worry about things like 
>> distributions, bias, and sampling.
> 
> Why do you mention “the role of a core language” here? That was explicitly 
> not the ambition of my question. I’m talking about extending the Standard 
> Library types and protocols in the Foundation framework (as this is already 
> done on a large scale). Or, if this is what you mean by “core language”, how 
> does capitalising strings according to the rules of grammar of every language 
> on the planet qualify as any more fitting the domain of the core language?
> 
> milos
> 

While I don't think general random sources are a good fit for core 
functionality, apparently, NSRandomSpecifier exists: 
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSRandomSpecifier_Class/index.html#//apple_ref/occ/cl/NSRandomSpecifier
 


Other material I consulted:
Standard Library: https://en.wikipedia.org/wiki/Standard_library 

Foundation: 
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/ObjC_classic/
 

 
GameplayKit Randomization: 
https://developer.apple.com/library/ios/documentation/General/Conceptual/GameplayKit_Guide/RandomSources.html#//apple_ref/doc/uid/TP40015172-CH9-SW1
 


-- E

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

Re: [swift-users] Looping through all values between UInt8.min and UInt8.max

[Erica Sadun via swift-users]

> On Apr 8, 2016, at 3:48 AM, tuuranton--- via swift-users 
>  wrote:
> 
> print(UInt8.min) //0
> 
> print(UInt8.max) //255
> 
> 
> 
> //Is there an easy way to loop between all values
> 
> //between (and including both) UInt8.min and UInt8.max?
> 
> 
> 
> //This doesn't work.
> 
> //Runtime crash because UInt8.max has no successor.
> 
> for i in UInt8.min...UInt8.max {
> 
> print(i)
> 
> }
> 
> 

Easy? No. 

// Range Index has no valid successor
for i in UInt8.min ... UInt8.max {
print(i)
}

// '...' cannot be applied to two 'UInt8' operands
for i in UInt8.min ... UInt8.max as ClosedInterval {
print(i)
}

// Stops at 254
for i in UInt8.min ..< UInt8.max {
print(i)
}


This works, but ugh:

for i : Int in numericCast(UInt8.min)...numericCast(UInt8.max) {
guard let j: UInt8 = UInt8(i) else { fatalError("Nope") }
print(j)
}

cc'ing in a few people to the white courtesy range phone.

-- E


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

[swift-users] Going a little crazy with the Swift Package Manager

[Erica Sadun via swift-users]

If anyone could kick the wheels and/or give feedback:

SwiftString  (should be okay on apple and 
linux)
SwiftUtility  (should be okay for apple 
and linux)
SwiftFoundationAdditions  
(best for non-linux, although I'm curious how they'll run on linux)

Please do let me know if you think there's anything there worth pushing forward 
to the language.

Thanks, -- Erica

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

Re: [swift-users] Lazily populated dictionary

[Erica Sadun via swift-users]

Maybe something like this?

struct KeyedLazyCache {
var backingDictionary: Dictionary
var builderDictionary: Dictionary U>
mutating func clear() {backingDictionary.removeAll()}
mutating func valueForKey(key: T) -> U? {
if let value = backingDictionary[key] {return value}
if let builder = builderDictionary[key] {
let value = builder()
backingDictionary[key] = value
return value
}
return nil
}
}

-- E

> On Dec 28, 2015, at 11:36 AM, Rudolf Adamkovič via swift-users 
>  wrote:
> 
> Hi there!
> 
> In my app, I have a very simple class that serves as a key-value cache. The 
> whole thing is basically a lazily populated [String: AVAudioPCMBuffer] 
> dictionary with a String -> AVAudioPCMBuffer function that generates values 
> as needed:
> 
> final class PlayerAudioCache {
> 
> // MARK: Retrieving audio buffers
> 
> func audioBufferForAssetWithName(name: String) -> AVAudioPCMBuffer? {
> addAudioBufferForAssetWithNameIfNeeded(name)
> return cachedAudioBuffers[name]
> }
> 
> // MARK: Adding audio buffers
> 
> func addAudioBufferForAssetWithNameIfNeeded(name: String) {
> guard cachedAudioBuffers[name] == nil else { return }
> addAudioBufferForAssetWithName(name)
> }
> 
> private func addAudioBufferForAssetWithName(name: String) {
> guard let dataAsset = NSDataAsset(name: name) else { fatalError() }
> cachedAudioBuffers[name] = dataAsset.map { URL -> AVAudioPCMBuffer in
> AVAudioPCMBuffer(contentsOfURL: URL)!
> }
> }
> 
> private var cachedAudioBuffers: [String: AVAudioPCMBuffer] = [:]
> 
> }
> 
> I feel like there is a pre-made type in Swift’s standard library for what I’m 
> doing here. Am I right?
> 
> Ideas? Pointers?
> 
> Thank you!
> 
> R+
> 
> ___
> 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] Setting up properties

[Erica Sadun via swift-users]

For a friend:

This won't work.

class DerpController {
private(set) var derp: Bool =  {
return _findDerp() != nil
}()

private func _findDerp() -> AnyObject? {
return nil
}
}


but this works:

private func _findDerp() -> AnyObject? {
return nil
}

class DerpController {
private(set) var derp: Bool =  {
return _findDerp() != nil
}()

}

Is it because the var member cannot depend on another member during setup? 
Thanks in advance for insight.___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Setting up properties

[Erica Sadun via swift-users]

Thanks. Passed that along back.

-- E


> On Dec 21, 2015, at 7:47 PM, Joe Groff  wrote:
> 
> Yeah, instance methods can't be called until `self` is fully initialized, 
> since they may themselves touch the uninitialized instance. In addition to 
> making the function global, you could also make it a static method to 
> preserve namespacing.

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

Re: [swift-users] Need better name, want to hide generator

[Erica Sadun via swift-users]

Here's what I ended up with. (The use-case for this ended up being light-weight 
game tile placement, not image processing or anything. )

func cartesianProduct(s1: S1, _ s2: S2) -> 
AnySequence<(S1.Generator.Element, S2.Generator.Element)> {
let items = s1.lazy.flatMap({
item1 in s2.lazy.map({
item2 in (item1, item2)})})
return AnySequence {items.generate()}
}

func cartesianProduct(s1: 
S1, _ s2: S2, _ s3: S3) -> AnySequence<(S1.Generator.Element, 
S2.Generator.Element, S3.Generator.Element)> {
let items = s1.lazy.flatMap({
item1 in s2.lazy.flatMap({
item2 in s3.lazy.map({
item3 in (item1, item2, item3)})})})
return AnySequence {items.generate()}
}

I initially suggested to the person I was helping:

for y in (...) {
for x in (...) {
  ...
}
}

But I'm glad I got to explore several alternative approaches. Thanks all. A few 
extra notes, to summarize everything into a single post:

Joe writes: "[AnySeq/Gen] aren't on the way out. We'd like to migrate them with 
first-class language support for protocol types with associated type 
constraints, but we wouldn't eliminate the functionality."

Dmitri adds: "You can use AnySequence and AnyGenerator, but they come at a cost 
of dynamic dispatch for every call.  In this case, if you want this component 
to be suitable for performance-critical code, I would suggest to avoid them for 
now."


-- E

> On Dec 18, 2015, at 11:08 PM, Rob Mayoff via swift-users 
>  wrote:
> 
> 1. Can anyone recommended a better name than Cartesian? 2D doesn't work for 
> the compiler and I'm looking for something that doesn't seem 
> "floating-point"-y
> 
> "AllPairs" seems self-explanatory.
> 
> "CrossJoin" should be intuitive to anyone familiar with relational databases.
> 
> "product" sounds like it might be multiplying elements with each other.
> 
>  ___
> 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] Need better name, want to hide generator

[Erica Sadun via swift-users]

Source: http://swiftstub.com/788132715 

Two questions:

1. Can anyone recommended a better name than Cartesian? 2D doesn't work for the 
compiler and I'm looking for something that doesn't seem "floating-point"-y
2. Is there a way to internalize the generator and not make it public? I'd 
ideally like to hide all details except the fact that this is a sequence of 
(Int, Int)

Thanks

-- Erica

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

Re: [swift-users] Need better name, want to hide generator

[Erica Sadun via swift-users]

At a minimum, this gives me http://swiftstub.com/60017598 
<http://swiftstub.com/60017598>

But I remember reading *somewhere* (can't remember) that we were supposed to 
avoid AnyGenerator/AnySequence and they were on the way out. Am I out of my 
mind?

-- E


> On Dec 18, 2015, at 2:47 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
> 
> Oops, of course I meant product(...) !
> 
> Jacob
> 
> On Fri, Dec 18, 2015 at 1:45 PM, Jacob Bandes-Storch <jtban...@gmail.com 
> <mailto:jtban...@gmail.com>> wrote:
> 1. Maybe ProductGenerator?
> 2. Use AnyGenerator<(T, U)>?
> 
> I'd love to see something like this in stdlib:
> 
> func product<S1, S2>(s1: S1, s2: S2) -> ProductSequence<S1.Generator.Element, 
> S2.Generator.Element> {
> ...
> }
> 
> where ProductSequence<T,U>.Generator.Element is (T, U).
> 
> So your example could be "for (x,y) in product(0..<4, 0..<2)".
> 
> Jacob Bandes-Storch
> 
> On Fri, Dec 18, 2015 at 1:22 PM, Erica Sadun via swift-users 
> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
> Source: http://swiftstub.com/788132715 <http://swiftstub.com/788132715>
> 
> Two questions:
> 
> 1. Can anyone recommended a better name than Cartesian? 2D doesn't work for 
> the compiler and I'm looking for something that doesn't seem 
> "floating-point"-y
> 2. Is there a way to internalize the generator and not make it public? I'd 
> ideally like to hide all details except the fact that this is a sequence of 
> (Int, Int)
> 
> Thanks
> 
> -- Erica
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users 
> <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] Using Swift for interpreted shell scripts?

[Erica Sadun via swift-users]

I've given up on it. I find it far easier to just write a command-line app with 
Xcode's source support -- E

> On Dec 15, 2015, at 12:45 PM, @lbutlr via swift-users  
> wrote:
> 
> Are there any resources on using swift for shell scripting?
> 
> I’m interested in trying my hand at Swift by converting existing bash scripts 
> into swift since bash is mostly what I am writing currently, so I figure this 
> will at least get me started with syntax and such.
> 
> ZZ

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

Re: [swift-users] Swift BMI

[Erica Sadun via swift-users]

And, of course, this is a perfect opportunity to use Swift tuple returns and 
eliminate the side-effect of printing the numeric value:

http://swiftstub.com/176972405

-- E, whose kids have a snow day this morning in case you can't tell


> On Dec 15, 2015, at 7:20 AM, Erica Sadun <er...@ericasadun.com> wrote:
> 
> In fact, there's no really good reason to use any construct, whether struct, 
> class, or enum, for this at all since the BMI isn't a "thing" per se.  A 
> global function might be a better fit.
> 
> http://swiftstub.com/443052056 <http://swiftstub.com/443052056>
> 
> -- E
> 
>> On Dec 15, 2015, at 7:10 AM, Eimantas Vaiciunas via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> I exchanged a class to an enum since the BMI values are a finite set. This 
>> eliminates a need for valid value check since the switch that is used to 
>> initialise the enum value is exhaustive.
>> 
>> http://swiftstub.com/242291010/ <http://swiftstub.com/242291010/>
>> 
>> On Tue, Dec 15, 2015 at 3:30 PM, Erica Sadun via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> Leaving aside typos, any discussion about the merits of BMI, and the 
>> intemperate language in the code, you do a few things that could be improved 
>> upon language-wise. Of these, the most egregious is the final "break the 
>> machine" else statement that can never be reached.
>> 
>> The following example does several things:
>> http://swiftstub.com/358512527 <http://swiftstub.com/358512527>
>> 
>> * Adds a precondition to ensure that clients have passed valid arguments
>> * Uses an enumeration (with a default value) instead of overloading a class 
>> function with nearly identical code
>> * Introduces a multiplier to address the kg/lb difference
>> * Establishes an upper case name for the class
>> * Uses a switch statement instead of cascaded ifs 
>> * Returns a String instead of running procedurally
>> 
>> -- E
>> 
>> 
>>> On Dec 14, 2015, at 8:20 PM, Gage Morgan via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>> 
>>> For most languages I try out, my own version of "Hello World!" is a BMI 
>>> calculator. Swift has passed, I encourage you to try it out. 
>>> 
>>> There are two methods called towards the end of file:
>>> 1) bmi.pounds(weight, height) - Replace numbers inside with your own if you 
>>> want to test out in US Customary units. 
>>> 
>>> 2) bmi.kilograms(weight, height) - Replace numbers inside with your own if 
>>> you want to test out in Metric units used everywhere outside the US. 
>>> 
>>> You already get the gist, the bits can be found here:
>>> https://gist.github.com/anonymous/9284017644567c29c7f8 
>>> <https://gist.github.com/anonymous/9284017644567c29c7f8>
>>> 
>>> If there's a bug please let me know, but it works in IBM's Sandbox. 
>>> (Yes, ALL code was written by me without help. Very close to C, just a bit 
>>> laid back.)
>>> --MGage--
>>> 
>>>  ___
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> <https://lists.swift.org/mailman/listinfo/swift-users>
>> 
>> 
>>  ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> <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] Swift BMI

[Erica Sadun via swift-users]

In fact, there's no really good reason to use any construct, whether struct, 
class, or enum, for this at all since the BMI isn't a "thing" per se.  A global 
function might be a better fit.

http://swiftstub.com/443052056

-- E

> On Dec 15, 2015, at 7:10 AM, Eimantas Vaiciunas via swift-users 
> <swift-users@swift.org> wrote:
> 
> I exchanged a class to an enum since the BMI values are a finite set. This 
> eliminates a need for valid value check since the switch that is used to 
> initialise the enum value is exhaustive.
> 
> http://swiftstub.com/242291010/ <http://swiftstub.com/242291010/>
> 
> On Tue, Dec 15, 2015 at 3:30 PM, Erica Sadun via swift-users 
> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
> Leaving aside typos, any discussion about the merits of BMI, and the 
> intemperate language in the code, you do a few things that could be improved 
> upon language-wise. Of these, the most egregious is the final "break the 
> machine" else statement that can never be reached.
> 
> The following example does several things:
> http://swiftstub.com/358512527 <http://swiftstub.com/358512527>
> 
> * Adds a precondition to ensure that clients have passed valid arguments
> * Uses an enumeration (with a default value) instead of overloading a class 
> function with nearly identical code
> * Introduces a multiplier to address the kg/lb difference
> * Establishes an upper case name for the class
> * Uses a switch statement instead of cascaded ifs 
> * Returns a String instead of running procedurally
> 
> -- E
> 
> 
>> On Dec 14, 2015, at 8:20 PM, Gage Morgan via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> For most languages I try out, my own version of "Hello World!" is a BMI 
>> calculator. Swift has passed, I encourage you to try it out. 
>> 
>> There are two methods called towards the end of file:
>> 1) bmi.pounds(weight, height) - Replace numbers inside with your own if you 
>> want to test out in US Customary units. 
>> 
>> 2) bmi.kilograms(weight, height) - Replace numbers inside with your own if 
>> you want to test out in Metric units used everywhere outside the US. 
>> 
>> You already get the gist, the bits can be found here:
>> https://gist.github.com/anonymous/9284017644567c29c7f8 
>> <https://gist.github.com/anonymous/9284017644567c29c7f8>
>> 
>> If there's a bug please let me know, but it works in IBM's Sandbox. 
>> (Yes, ALL code was written by me without help. Very close to C, just a bit 
>> laid back.)
>> --MGage--
>> 
>>  ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> <https://lists.swift.org/mailman/listinfo/swift-users>
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users 
> <https://lists.swift.org/mailman/listinfo/swift-users>
> 
> 
>  ___
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users 
> <https://lists.swift.org/mailman/listinfo/swift-users>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users