There are several hurdles with beginning the Swift track would benefit from some attention. I am very new to exercism and somewhat new to programming, and I respect how much work it is to create these assets. These observations are offered as constructive criticism, and I do not mean to disparage the work already performed.

1. The "Running the Tests" instructions are based on the bob exercise, rather than the hello-world exercise.
2. The source files retrieved by the fetch operation for the hello-world exercise are not helpful as they do not match other exercises. For example, most exercises fetch two source documents, tests and a readme. Hello World contains an Xcode project and directory. And worse, the fetched Xcode project does not build as a standalone project.

These two issues created a lot of false inferences on my part as I tried to get up to speed. I ultimately worked out how exercism worked with Swift by finding the backing GitHub repositories for bob and hello-world, and comparing them to the instructions.

Recommendations

The "Running the Tests" instructions for Swift are strictly correct, although I still found them confusing until I figured out the basic workflow. (Again hello-world sent me off in the wrong direction initially.)

A few specific notes that might help make the running test instructions mode complete.

a. Note that its better to use iOS Single View application even if you're ultimately going to work on OS X apps.

b. I think asking newer developers to create a class file outside Xcode's normal default is a tall order, and it would be better to leave it in place. Then demonstrate how to submit it by dragging and dropping the class file from Xcode into the terminal window.

c. describe briefly difference between unit tests and compiling the project

d. add several additional images.

Expanding on the Running the Tests instructions to explain both how to create a new project and how to upload the final submission is something I would like to contribute to, but I'm not sure how. I love the whole exercism concept and would love to contribute back to it.

In an effort to get rid of the Xcode warning, we should implement the sample code for BinarySearchTree using indirect enums.
#147

Using Xcode 8-Beta-6, building the tests fail to build in testAccumulateRecursively() because Cannot invoke 'XCTAssertEqual' with an argument list of type '([Array<String>], [[String]])'.

I have tested many of the submitted answers as well as the example in the xswift repo and they are all failing in the same way.

There are a couple changes I needed to make to even get to this point.

First thing is that the extension(or function) needs to be declared public now or the build will fail.

The next thing is to add the _ before the parameter name so it is not required in the call.

It appears that there needs to be another extension to make [Array<String>] Equatable? I tried, but failed to wrap my head around it. How do we test equality on this now?

Having a lot of fun doing these exercises, @hankturowski.

Wordcount is the first swift exercism that uses XCTAssertEqualObjects but it seems to be gone from XCode 6 Beta 4 (I don't know when that happened).

I tried using XCTAssertEqual but Dictionaries don't seem to implement Equatable?

What am I missing?

In order to reduce the amount of code required to pass incremental tests (assuming that users pass tests starting from the top), the order of the tests was modified slightly.

Since this track implements Custom Set, please take a look at the new custom-set.json file and see if your track should update its tests.

If you do need to update your tests, please refer to this issue in your PR. That helps us see which tracks still need to update their tests.

If your track is already up to date, go ahead and close this issue.

More details on this change are available in exercism/problem-specifications#257.

For the test func testSortSchool() we want to return an object that is sorted by keys and values of the dictionary. It seems like the test is working too hard and may not even be right, since the keys in a Swift Dictionary are not ordered.
Instead of
let expected = [ 3 : ["Kyle"], 4 : [ "Christopher", "Jennifer" ], 6 : [ "Kareem"] ]
We should return
let expected = [ (3,["Kyle"]), (4,["Christopher", "Jennifer"] ), (6, ["Kareem"])]

Also tuples are the swift way to return groups of multiple values.
I am still new to swift :) but I was at WWDC and showed my code to some devs at the swift lab. This was their suggestion.

There is an interesting edge case in the meetup problem:
some months have five Mondays.

March of 2015 has five Mondays (the fifth being March 30th), whereas
February of 2015 does not, and so should produce an error.

Thanks, @JKesMc9tqIQe9M for pointing out the edge case.
See exercism.io#2142.

This course is apparently really good. I came across it from here: https://medium.com/ios-os-x-development/apple-has-published-a-great-free-learn-to-code-course-for-swift-on-github-feb5e4d70691

So my code looks like this

func isLeapYear() -> Bool { ... }

Which Xcode complains about with the following errors when I run the tests

Function produces expected type 'Bool'; did you mean to call it with '()'?

and for the ! tests

cannot invoke 'XCTAssertTrue' with an argument list of type '(Bool)'

However, when I change the tests from

XCTAssertTrue(!year.isLeapYear)

to

XCTAssertTrue(!year.isLeapYear())

Everything seems to work fine and the tests pass (because I have logic written for them that is excluded from this issue note).

I'm just curious as to what is going on here. I looked at the example answer you guys have in here, and instead of declaring isLeapYear to be a function, you invoke it as a local variable which passes the tests without having to add the parentheses.

var isLeapYear: Bool { ... }

I know that parentheses mean that you are calling some function on an object, but what are the major differences with this kind of implementation? When is it best to apply one over the other? Was the way I was constructing it as a function incorrect? I'm brand new to Swift (and programming in general, really), so some of these one-off things always take my head for a spin. If anyone would be able to clear it up I would be very appreciative.

The JSON file containing canonical inputs/outputs for the Clock exercise has gotten new data.

There are two situations that the original data didn't account for:

• Sometimes people perform computation/mutation in the display method instead of in add. This means that you might have two copies of clock that are identical, and if you add 1440 minutes to one and 2880 minutes to the other, they display the same value but are not equal.
• Sometimes people only account for one adjustment in either direction, meaning that if you add 1,000,000 minutes, then the clock would not end up with a valid display time.

If this track has a generator for the Clock exercise, go ahead and regenerate it now. If it doesn't, then please verify the implementation of the test suite against the new data. If any cases are missing, they should be added.

See exercism/problem-specifications#166

Here is the current list of problems with the number of submissions per each problem.
@hankturowski you are right about the Bob problem. 54% of people drop out of the track on the second problem!

Leap (126)
Bob (58)
Hamming (47)
Word Count (48)
Etl (35)
Anagram (34)
Nucleotide Count (30)
Phone Number (24)
Grade School (18)
Robot Name (22)
Perfect Numbers (16)
Allergies (12)
Accumulate (11)
Sum Of Multiples (9)
Twelve Days (9)
Space Age (10)
Gigasecond (8)
Meetup (5)
Triangle (5)
Scrabble Score (6)
Roman Numerals (5)
Binary (4)
Prime Factors (3)
Raindrops (4)
Strain (5)
Atbash Cipher (5)
Crypto Square (5)
Trinary (4)
Rna Transcription (4)
Sieve (4)
Octal (4)
Luhn (4)
Series (4)
Pig Latin (4)
Pythagorean Triplet (4)
Difference Of Squares (4)
Secret Handshake (4)
Clock (3)
Simple Linked List (2)

#54

Please check if there's a test that states that a triangle with sides 2, 4, 2 is invalid. The triangle inequality states that for any triangle, the sum of the lengths of any two sides must be greater than or equal to the length of the remaining side. If this doesn't affect this track, go ahead and just close the issue.

From issue exercism/exercism#1867

Wikipedia says the Hamming distance is not defined for strings of different length.

I am not saying the problems cannot be different, but for such a well-defined concept it would make sense to stick to one definition, especially when the READMEs provide so little information about what is expected from the implementation.

Let's clean this up so that we're using the official definition.

Swift 2.2 is able to run on Ubuntu Linux.
Microsoft just made their Ubuntu subsystem avalible to windows as Beta.
https://insights.ubuntu.com/2016/04/14/howto-ubuntu-on-windows-2/

I believe the best time to transition would be when swift 3 becomes available (end of 2016)
We would need to update the instructions on how to run on Linux, Windows and macOS with our using xcode.

Reference:
#141

We should have separate tests for:

• alphabetic characters at the beginning of a valid binary number
• alphabetic characters at the end of a valid binary number
• alphabetic characters in the middle of an otherwise valid binary number
• invalid digits (e.g. 2)

If the test suite for binary has test cases that cover these edge cases, this issue can safely be closed.

See exercism/problem-specifications#95

I am not sure if this is the right platform to raise this question/issue, but I am working thru the Allergies problem and I just can't figure out why the tests don't require the use of a swift enum to store the different allergies? I am able to get the tests to pass using static properties for the Allergies struct, but this excersise would look much prettier with an enum.

Wait for swift 2 to come out of beta.

Prefer the native Swift types over the Objective-C counterparts.
#54

Switch some test to throw errors instead of nil when it makes sense
http://ericasadun.com/2015/07/28/nil-vs-throws-swiftlang/

Make use of more Enums in tests ( Specially now that Enums with String payloads get automatically converted to strings)

Make use of Generic extensions.

How to test out Protocol usage in tests?

On the learning resources page (http://exercism.io/languages/swift#learning), Swifty App is a good start. I would also add Apple's free iBook, The Swift Programming Language, which is pretty accessible: https://itunes.apple.com/us/book/the-swift-programming-language/id881256329?mt=11

I think this we need to optimize this example because it is taking more than a minute to run 5 test when it should only take a couple of seconds at most.

Test Suite 'PalindromeProductsTest' started at 2016-03-14 18:58:19.629
Test Case '-[xSwiftTests.PalindromeProductsTest testLargestPalindromeFromDoubleDigitFactors]' started.
Test Case '-[xSwiftTests.PalindromeProductsTest testLargestPalindromeFromDoubleDigitFactors]' passed (0.231 seconds).
Test Case '-[xSwiftTests.PalindromeProductsTest testLargestPalindromeFromSingleDigitFactors]' started.
Test Case '-[xSwiftTests.PalindromeProductsTest testLargestPalindromeFromSingleDigitFactors]' passed (0.002 seconds).
Test Case '-[xSwiftTests.PalindromeProductsTest testLargestPalindromeFromTripleDigitFactors]' started.
Test Case '-[xSwiftTests.PalindromeProductsTest testLargestPalindromeFromTripleDigitFactors]' passed (34.046 seconds).
Test Case '-[xSwiftTests.PalindromeProductsTest testSmallestPalindromeFromDoubleDigitFactors]' started.
Test Case '-[xSwiftTests.PalindromeProductsTest testSmallestPalindromeFromDoubleDigitFactors]' passed (0.232 seconds).
Test Case '-[xSwiftTests.PalindromeProductsTest testSmallestPalindromeFromTripleDigitFactors]' started.
Test Case '-[xSwiftTests.PalindromeProductsTest testSmallestPalindromeFromTripleDigitFactors]' passed (33.415 seconds).
Test Suite 'PalindromeProductsTest' passed at 2016-03-14 18:59:27.557.
     Executed 5 tests, with 0 failures (0 unexpected) in 67.926 (67.928) seconds

exercism/objective-c#27

Create Empty Xcode File
exercism/exercism#2401 (comment)

Update WorkFlow.md
Use this tutorial as a basis to update the WorkFlow.md file
http://samuelmullen.com/2014/09/unit-testing-in-swift/

Example Solution to HelloWorld

struct HelloWorld{
    static func hello( _ input:String = "World") -> String{
        return "Hello, \(input)!"
    }
}

Hello World Test File

import XCTest

class  HelloWorldTest: XCTestCase {

    func testNoName(){
        let expected = "Hello, World!"
        XCTAssertEqual(HelloWorld.hello(), expected, "When given no name, we should greet the world!")
    }

    func testSampleName(){
        let expected = "Hello, Alice!"
        XCTAssertEqual(HelloWorld.hello("Alice"), expected, "When given 'Alice', we should greet Alice!")
    }

    func testOtherSampleName(){
        let expected = "Hello, Bob!"
        XCTAssertEqual(HelloWorld.hello("Bob"), expected, "When given 'Bob', we should greet Bob!")
    }

    func testNoStrangeName(){
        let expected = "Hello, !"
        XCTAssertEqual(HelloWorld.hello(""), expected, "When given an empty string, it is strange, but should have a space and punctuation")
    }

}

So how do you run these from the CLI?

Hello, as part of exercism/problem-specifications#198 we'd like to make the sum of multiples exercise less confusing. Currently, the README specifies that if no multiples are given it should default to 3 and 5.

We'd like to remove this default, so that a list of multiples will always be specified by the caller. This makes the behavior explicit, avoiding surprising behavior and simplifying the problem.

Please make sure this track's tests for the sum-of-multiples problem do not expect such a default. Any tests that want to test behavior for multiples of [3, 5] should explicitly pass [3, 5] as the list of multiples.

After all tracks have completed this change, then exercism/problem-specifications#209 can be merged to remove the defaults from the README.

The reason we'd like this change to happen before changing the README is that it was very confusing for students to figure out the default behavior. It wasn't clear from simply looking at the tests that the default should be 3 and 5, as seen in exercism/exercism#2654, so some had to resort to looking at the example solutions (which aren't served by exercism fetch, so they have to find it on GitHub). It was added to the README to fix this confusion, but now we'd like to be explicit so we can remove the default line from the README.

You can find the common test data at https://github.com/exercism/x-common/blob/master/sum-of-multiples.json, in case that is helpful.

The word multibillionaire is too long for the scrabble board. Oxyphenbutazone, on the other hand, is legal.

Please verify that there is no test for multibillionaire in the scrabble-score in this track. If the word is included in the test data, then it should be replaced with oxyphenbutazone. Remember to check the case (if the original is uppercase, then the replacement also should be).

If multibillionaire isn't used, then this issue can safely be closed.

See exercism/problem-specifications#86

I made a really stupid choice a while back to commit the cross-compiled
binaries for configlet (the tool that sanity-checks the config.json
against the implemented problems) into the repository itself.

Those binaries are HUGE, and every time they change the entire 4 or 5 megs get
recommitted. This means that cloning the repository takes a ridiculously long
time.

I've added a script that can be run on travis to grab the latest release from
the configlet repository (bin/fetch-configlet), and travis is set up to run
this now instead of using the committed binary.

I would really like to thoroughly delete the binaries from the entire git
history, but this will break all the existing clones and forks.

The commands I would run are:

# ensure this happens on an up-to-date master
git checkout master && git fetch origin && git reset --hard origin/master

# delete from history
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch bin/configlet-*' --prune-empty

# clean up
rm -rf .git/refs/original/
git reflog expire --all
git gc --aggressive --prune

# push up the new master, force override existing master branch
git push -fu origin master

If we do this everyone who has a fork will need to make sure that their master
is reset to the new upstream master:

git checkout master
git fetch upstream master
git reset --hard upstream/master
git push -fu origin master

We can at-mention (@) all the contributors and everyone who has a fork here in this
issue if we decide to do it.

The important question though, is: Is it worth doing?

Do you have any other suggestions of how to make sure this doesn't confuse people and break their
repository if we do proceed with this change?

The metadata for this problem has been simplified, and it might be worth changing the test suite and example so that theres no mention of RNA or uracil.

I've also changed the API of the problem in Ruby so that there is no error checking in the object itself, only in the factory that creates it: https://github.com/exercism/xruby/blob/master/nucleotide-count/example.rb#L2-L8

I don't know if this is relevant or idiomatic in Swift.

This may or may not be appropriate in this language. See exercism/docs#54 for details.

• Replace Some optional returns for throws when it makes sense
• Prefer encapsulation instead of free functions.
• Protocol usage when it makes sense
• Make extensions private
• Guard or if lets instead of !

The documentation to begin working through the Swift exercises could use some clarification. It's a multi-step process to integrate the test file with a new project, solve the exercise, and submit correctly.

1. Create a new project with Xcode, in the same folder as the Exercism test file:
   
2. Drag the Exercism test file into the <project_name>Tests group, and add the line @testable import <project_name> on the second line of the Exercism test file:
   
3. Create the working file/class, and save in the same folder as the Exercism test file: [see first image]
4. When you are ready to submit, do so from the folder that contains the working file and the Exercism test file

The last test of accumulate uses a function whose signature is (String) -> [String]. All of the other tests take a function argument whose signature is (T) -> T. I believe this last test is incorrect unless there's another way to write accumulate that handles this.

The latest Swift exercises (all-your-base and bracket-push) are still not present on exercism.io, even though an Objective-C exercise merged afterward is.

SwiftLint produces the following crash in Xcode 8 beta 5:

dyld: Library not loaded: @rpath/libclang.dylib Referenced from: /usr/local/Cellar/swiftlint/0.7.2/Frameworks/SwiftLintFramework.framework/Versions/A/SwiftLintFramework Reason: image not found /Users/robhudson/Library/Developer/Xcode/DerivedData/xSwift-gjctigreqseescdsxuoxmjrrpkpw/Build/Intermediates/xSwift.build/Debug/xSwiftTests.build/Script-1EB3CC5A1D307D8000F72FAC.sh: line 7: 52351 Trace/BPT trap: 5 swiftlint Command /bin/sh failed with exit code 133

There was some confusion in this exercise due to the ambiguous use of the term consecutive in the README. This could be taken to mean contiguous, as in consecutive by position, or as in consecutive numerically. The the README has been fixed (exercism/problem-specifications#200).

Please verify that the exercise is implemented in this track correctly (that it finds series of contiguous numbers, not series of numbers that follow each other consecutively).

If it helps, the canonical inputs/outputs for the exercise can be found here:
https://github.com/exercism/x-common/blob/master/largest-series-product.json

If everything is fine, go ahead and just close this issue. If there's something to be done, then please describe the steps needed in order to close the issue.

exercism/ruby#102
"The only restriction is that the example file needs to have /[Ee]xample/ in the name" - @kytrinyx

I want to understand why the test files can be different names but the examples files names need to be "/[Ee]xample/ ". In an xcode project I can't have the same filename for different files in the same project because the project wont compile. Having all the problems in one project would allow faster updates of language changes ( 1.x to 1.x+ ) and in the future Travis integration.

http://docs.travis-ci.com/user/osx-ci-environment/
http://docs.travis-ci.com/user/languages/objective-c/

exercism/exercism#316

See issue exercism/exercism#2092 for an overview of operation welcome contributors.

Provide instructions on how to contribute patches to the exercism test suites
and examples: dependencies, running the tests, what gets tested on Travis-CI,
etc.

The contributing document
in the x-api repository describes how all the language tracks are put
together, as well as details about the common metadata, and high-level
information about contributing to existing problems, or adding new problems.

The README here should be language-specific, and can point to the contributing
guide for more context.

From the OpenHatch guide:

Here are common elements of setting up a development environment you’ll want your guide to address:

Preparing their computer
Make sure they’re familiar with their operating system’s tools, such as the terminal/command prompt. You can do this by linking to a tutorial and asking contributors to make sure they understand it. There are usually great tutorials already out there - OpenHatch’s command line tutorial can be found here.
If contributors need to set up a virtual environment, access a virtual machine, or download a specific development kit, give them instructions on how to do so.
List any dependencies needed to run your project, and how to install them. If there are good installation guides for those dependencies, link to them.

Downloading the source
Give detailed instructions on how to download the source of the project, including common missteps or obstacles.

How to view/test changes
Give instructions on how to view and test the changes they’ve made. This may vary depending on what they’ve changed, but do your best to cover common changes. This can be as simple as viewing an html document in a browser, but may be more complicated.

Installation will often differ depending on the operating system of the contributor. You will probably need to create separate instructions in various parts of your guide for Windows, Mac and Linux users. If you only want to support development on a single operating system, make sure that is clear to users, ideally in the top-level documentation.

The contents of the SETUP.md file gets included in
the README.md that gets delivered when a user runs the exercism fetch
command from their terminal.

At the very minimum, it should contain a link to the relevant
language-specific documentation on
help.exercism.io.

It would also be useful to explain in a generic way how to run the tests.
Remember that this file will be included with all the problems, so it gets
confusing if we refer to specific problems or files.

Some languages have very particular needs in terms of the solution: nested
directories, specific files, etc. If this is the case here, then it would be
useful to explain what is expected.

Thanks, @tejasbubane for suggesting that we add this documentation everywhere.
See exercism.io#2198.

For the past three years, the ordering of exercises has been done based on gut feelings and wild guesses. As a result, the progression of the exercises has been somewhat haphazard.

In the past few months maintainers of several tracks have invested a great deal of time in analyzing what concepts various exercises require, and then reordering the tracks as a result of that analysis.

It would be useful to bake this data into the track configuration so that we can adjust it over time as we learn more about each exercise.

To this end, we've decided to add a new key exercises in the config.json file, and deprecate the problems key.

See exercism/discussions#60 for details about this decision.

Note that we will not be removing the problems key at this time, as this would break the website and a number of tools.

The process for deprecating the old problems array will be:

• Update all of the track configs to contain the new exercises key, with whatever data we have.
• Simultaneously change the website and tools to support both formats.
• Once all of the tracks have added the exercises key, remove support for the old key in the site and tools.
• Remove the old key from all of the track configs.

In the new format, each exercise is a JSON object with three properties:

• slug: the identifier of the exercise
• difficulty: a number from 1 to 10 where 1 is the easiest and 10 is the most difficult
• topics: an array of strings describing topics relevant to the exercise. We maintain
  a list of common topics at https://github.com/exercism/x-common/blob/master/TOPICS.txt. Do not feel like you need to restrict yourself to this list;
  it's only there so that we don't end up with 20 variations on the same topic. Each
  language is different, and there will likely be topics specific to each language that will
  not make it onto the list.

The difficulty rating can be a very rough estimate.

The topics array can be empty if this analysis has not yet been done.

Example:

"exercises": [
  {
    "slug": "hello-world" ,
    "difficulty": 1,
    "topics": [
        "control-flow (if-statements)",
        "optional values",
        "text formatting"
    ]
  },
  {
    "difficulty": 3,
    "slug": "anagram",
    "topics": [
        "strings",
        "filtering"
    ]
  },
  {
    "difficulty": 10,
    "slug": "forth",
    "topics": [
        "parsing",
        "transforming",
        "stacks"
    ]
  }
]

It may be worth making the change in several passes:

1. Add the exercises key with the array of objects, where difficulty is 1 and topics is empty.
2. Update the difficulty settings to reflect a more accurate guess.
3. Add topics (perhaps one-by-one, in separate pull requests, in order to have useful discussions about each exercise).

This is more of a place holder as today Apple is going to release the new GM Xcode 6.3 with Swift 1.2. I Don't expect tests to change much though.

In exercism/problem-specifications#44 @masters3d submitted a fix to account for daylight savings time, but since not all locales have daylight savings time, I'd rather ignore that aspect of the problem.

Can someone confirm whether or not the swift Gigasecond problem takes the daylight savings into account?

A simple comment like so
// 09-14-15 Swift 2.0

Some solutions mistakenly assume if the input has 1 domino it's always valid. This isn't always the case, so we should test for this by adding a test where the input has one domino (1, 2). Adding in exercism/rust#96 , and it's just Rust and Swift that have the dominoes implemented.

The problems api (x-api) now supports having exercises collected in a subdirectory
named exercises.

That is to say that instead of having a mix of bin, docs, and individual exercises,
we can have bin, docs, and exercises in the root of the repository, and all
the exercises collected in a subdirectory.

In other words, instead of this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── bowling
│   ├── bowling_test.ext
│   └── example.ext
├── clock
│   ├── clock_test.ext
│   └── example.ext
├── config.json
└── docs
│   ├── ABOUT.md
│   └── img
... etc

we can have something like this:

x{TRACK_ID}/
├── LICENSE
├── README.md
├── bin
│   └── fetch-configlet
├── config.json
├── docs
│   ├── ABOUT.md
│   └── img
├── exercises
│   ├── bowling
│   │   ├── bowling_test.ext
│   │   └── example.ext
│   └── clock
│       ├── clock_test.ext
│       └── example.ext
... etc

This has already been deployed to production, so it's safe to make this change whenever you have time.

now that travis is running tests, any new addition to the repo needs to be added to the xcode so that travis passes

#63

We recently rewrote the test suite for Custom Set. Since this track implements Custom Set, please take a look at the new custom_set.json file and see if your track should update its implementation or tests.

The new test suite reorders tests so that students can get to green quickly. It also reduces the number of tests so that students can focus on solving the interesting edge cases.

More details on this change are available in the pull request

Xcode 8 now includes XCTAssertThrowsError, which can be used to test that a specific Swift error is thrown.

• Update all tests that confirm a Swift error is thrown to use this method.

I can't remember the history of this, but we ended up with a weird non-biological thing in the RNA transcription exercise, where some test suites also have tests for transcribing from RNA back to DNA. This makes no sense.

If this track does have tests for the reverse transcription, we should remove them, and also simplify the reference solution to match.

If this track doesn't have any tests for RNA->DNA transcription, then this issue can be closed.

See exercism/problem-specifications#148

@kytrinyx Do you know how (or know who) to edit the travis script so that the current script wont break?
https://github.com/exercism/xswift/blob/master/.travis.yml

I'd like to add xcode build to to run the tests on Xcode project.
http://docs.travis-ci.com/user/languages/objective-c/#Default-Test-Script

#42

Swift and the Swift standard library are going to be open sourced by the end of 2015.
This got me thinking about the use of Foundation classes ( NSDate, NSMutableArray, NSString etc ) in the problems.

Should we make it a point to decouple the tests and examples to focus on "pure" swift implementations since Foundation is not going to be available for Linux?
In xcode 7 beta 5 there were some changes to NString and String that dealt with paths.
https://forums.developer.apple.com/thread/13688

This is an indication that swift types are becoming more "pure" maybe because of the open source release.

This would mean not importing foundation.
Edit: 9-9-15

Current list of problems that depend on Foundation.

• /acronym/AcronymExample.swift // No Native Swift for NSExpression
• /bob/BobExample.swift // No Native Swift for NSExpression
• /gigasecond/GigasecondExample.swift // No Native Swift for NSDate
• /meetup/MeetupExample.swift // No Native Swift for NSDate
• /word-count/WordCountExample.swift //NSStringCompareOptions
• /wordy/WordyExample.swift //NSStringCompareOptions

• kindergarten-garden
• robot-simulator
• queen-attack
• binary-search-tree
• hexadecimal
• largest-series-product
• matrix
• house
• minesweeper
• ocr-numbers
• food-chain
• custom-set
• nth-prime
• palindrome-products
• pascals-triangle
• saddle-points

Reference
exercism/java#3
exercism/exercism#316