www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OT: Swift is now open source

reply Jack Stouffer <jack jackstouffer.com> writes:
https://github.com/apple/swift
Dec 03 2015
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 3 December 2015 at 17:13:49 UTC, Jack Stouffer wrote:
 https://github.com/apple/swift
Fun Fact: in the time it took apple to open source this (announcement to now), D has had six open source releases (2.068 - 2.069.2).
Dec 03 2015
parent Joakim <dlang joakim.fea.st> writes:
On Thursday, 3 December 2015 at 17:19:03 UTC, Jack Stouffer wrote:
 On Thursday, 3 December 2015 at 17:13:49 UTC, Jack Stouffer 
 wrote:
 https://github.com/apple/swift
Fun Fact: in the time it took apple to open source this (announcement to now), D has had six open source releases (2.068 - 2.069.2).
Multiple mentions of D in the last paragraphs of the recent Wired article about Swift finally getting open-sourced: http://www.wired.com/2015/12/apple-open-sources-its-swift-programming-language/
Dec 06 2015
prev sibling next sibling parent reply tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
On Thursday, 3 December 2015 at 17:13:49 UTC, Jack Stouffer wrote:
 https://github.com/apple/swift
Everytime I get excited about another programming language, I notice that it lacks some nice features of D, and I become sad Java programmers are not aware of what things they are missing :D D lacks some features as well, but I do not want to talk about them here. Some people in the forum are getting into defence and attack mode immediately.
Dec 03 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 3 December 2015 at 17:56:49 UTC, tcak wrote:
 On Thursday, 3 December 2015 at 17:13:49 UTC, Jack Stouffer 
 wrote:
 https://github.com/apple/swift
Everytime I get excited about another programming language, I notice that it lacks some nice features of D, and I become sad suddenly.
Which features do you miss the most in Swift? My first reaction is: the code base seems to be readable, and with comments sprinkled in. Looks like a reasonable starting-point for someone wanting to create their own dialect of a high level language.
 Some people in the forum are getting into defence and attack 
 mode immediately.
They are just acting. I hope.
Dec 03 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/3/15 12:56 PM, tcak wrote:
 On Thursday, 3 December 2015 at 17:13:49 UTC, Jack Stouffer wrote:
 https://github.com/apple/swift
Everytime I get excited about another programming language, I notice that it lacks some nice features of D, and I become sad suddenly. Even of what things they are missing :D D lacks some features as well, but I do not want to talk about them here. Some people in the forum are getting into defence and attack mode immediately.
The truth is, swift is orders of magnitude better than Objective C. I have gotten used to the nullable API, though it sometimes seems more clunky than useful. While it succeeds in preventing me from incorrectly using nil objects, it sometimes results in my code not executing because I wrapped it in an if-let! Apple's API is still rather verbose and hard to discover, but that is not swift's fault. And the lack of semi-colons has poisoned me from writing syntactically valid lines in D :) I miss D's algorithms and range API when working with swift. A lot. I've tried to use their sequence API, but it's very confusing. -Steve
Dec 03 2015
next sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 3 December 2015 at 19:10:04 UTC, Steven 
Schveighoffer wrote:
 And the lack of semi-colons has poisoned me from writing 
 syntactically valid lines in D :)
Surprisingly (or not), lack of semicolons is something that I Ruby. There's a lot to be said for the little quality of life features in a language.
Dec 03 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 3 December 2015 at 20:16:50 UTC, Meta wrote:
 Surprisingly (or not), lack of semicolons is something that I 

 tried Ruby. There's a lot to be said for the little quality of 
 life features in a language.
I, on the other hand, can't use languages without semicolons... It is like trying to write English without full stops. I can go back and hit delete, but my fingers instinctively end thoughts with it. There's other benefits too but the habit is the big one for me.
Dec 03 2015
parent karabuta <karabutaworld gmail.com> writes:
On Thursday, 3 December 2015 at 20:22:39 UTC, Adam D. Ruppe wrote:
 On Thursday, 3 December 2015 at 20:16:50 UTC, Meta wrote:
 Surprisingly (or not), lack of semicolons is something that I 

 tried Ruby. There's a lot to be said for the little quality of 
 life features in a language.
I, on the other hand, can't use languages without semicolons... It is like trying to write English without full stops. I can go back and hit delete, but my fingers instinctively end thoughts with it. There's other benefits too but the habit is the big one for me.
That is why I cannot stay with any programming language except PHP, C, JS & of course D. I still struggle(fell uncomfortable) with python even thought it has some tools I need at times.
Dec 04 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/3/15 3:16 PM, Meta wrote:
 On Thursday, 3 December 2015 at 19:10:04 UTC, Steven Schveighoffer wrote:
 And the lack of semi-colons has poisoned me from writing syntactically
 valid lines in D :)
Surprisingly (or not), lack of semicolons is something that I have There's a lot to be said for the little quality of life features in a language.
You may misunderstand -- I prefer semicolons. But having to write swift code for a few weeks, I find now when I write D code I forget them all the time (where usually my proper semi-colon rate is near 100%). -Steve
Dec 03 2015
parent reply tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
On Thursday, 3 December 2015 at 20:37:04 UTC, Steven 
Schveighoffer wrote:
 On 12/3/15 3:16 PM, Meta wrote:
 On Thursday, 3 December 2015 at 19:10:04 UTC, Steven 
 Schveighoffer wrote:
 And the lack of semi-colons has poisoned me from writing 
 syntactically
 valid lines in D :)
Surprisingly (or not), lack of semicolons is something that I have Ruby. There's a lot to be said for the little quality of life features in a language.
You may misunderstand -- I prefer semicolons. But having to write swift code for a few weeks, I find now when I write D code I forget them all the time (where usually my proper semi-colon rate is near 100%). -Steve
Since you have experience, what is the level of the language? Is it C or Javascript level? It is not clear by looking at example codes, and I do not have much time these days to try anything new. (My first post was written by looking at code examples.) Are you able to define C bindings? Can I do socket programming? Are Posix function accessible? How is the speed?
Dec 03 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/3/15 9:59 PM, tcak wrote:
 On Thursday, 3 December 2015 at 20:37:04 UTC, Steven Schveighoffer wrote:
 On 12/3/15 3:16 PM, Meta wrote:
 On Thursday, 3 December 2015 at 19:10:04 UTC, Steven Schveighoffer
 wrote:
 And the lack of semi-colons has poisoned me from writing syntactically
 valid lines in D :)
Surprisingly (or not), lack of semicolons is something that I have There's a lot to be said for the little quality of life features in a language.
You may misunderstand -- I prefer semicolons. But having to write swift code for a few weeks, I find now when I write D code I forget them all the time (where usually my proper semi-colon rate is near 100%).
Since you have experience, what is the level of the language? Is it C or Javascript level?
It is meant to be a replacement for Objective C. I'd put it more at the C level, but there are something that are very UNLIKE C. For example, they do not have any direct instance variables, everything is a property. There seem to be no low-level types, even 'Int' is a struct. But I assume the compiler whisks that away. The type system is static, and everything is done via inference, which is very nice. The nullable unwrapping system takes a while to get used to.
 Are you able to define C bindings? Can I do socket programming? Are
 Posix function accessible? How is the speed?
See here: http://stackoverflow.com/questions/24004732/how-to-call-c-from-swift You basically need a bridging header that defines what can be called from swift. I don't know the details of what happens in the compiler for this. Speed wise, I can't be sure. I'm sure others here have a better understanding. All I've used it for so far is UI code on iOS. Usability-wise, it's much easier to write swift than Objective C. One thing I would LOVE to see in D from swift is inference of enum names. In D-speak, it looks like this: enum Foo { Bar, Baz } Foo foo; switch(foo) { case .Bar: // Foo is implied case .Baz: } void fun(Foo); fun(.Bar); // Foo is implied I don't think we could have this exact syntax, though. -Steve
Dec 03 2015
next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Friday, 4 December 2015 at 03:18:02 UTC, Steven Schveighoffer 
wrote:
 On 12/3/15 9:59 PM, tcak wrote:
 [...]
It is meant to be a replacement for Objective C. I'd put it more at the C level, but there are something that are very UNLIKE C. For example, they do not have any direct instance variables, everything is a property. There seem to be no low-level types, even 'Int' is a struct. But I assume the compiler whisks that away. [...]
switch(foo) with foo { case Bar: case Baz: } ?
Dec 03 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/3/15 10:22 PM, rsw0x wrote:
 On Friday, 4 December 2015 at 03:18:02 UTC, Steven Schveighoffer wrote:
 On 12/3/15 9:59 PM, tcak wrote:
 [...]
It is meant to be a replacement for Objective C. I'd put it more at the C level, but there are something that are very UNLIKE C. For example, they do not have any direct instance variables, everything is a property. There seem to be no low-level types, even 'Int' is a struct. But I assume the compiler whisks that away. [...]
switch(foo) with foo { case Bar: case Baz: }
Yes, I know that trick. In swift, everywhere you are using/expecting a Foo, it allows the shortcut. It's very nice when you are doing things that require a lot of enum function parameters (UI has a lot of this). -Steve
Dec 03 2015
parent reply rcorre <ryan rcorre.net> writes:
On Friday, 4 December 2015 at 03:38:23 UTC, Steven Schveighoffer 
wrote:

 Yes, I know that trick. In swift, everywhere you are 
 using/expecting a Foo, it allows the shortcut.

 It's very nice when you are doing things that require a lot of 
 enum function parameters (UI has a lot of this).

 -Steve
Do you mean something like: enum Foo { bar, baz } void fun(Foo foo) { } fun(baz); I don't really mind having to use switch/with but I've found myself wishing for the above on occasion.
Dec 04 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-12-04 13:35, rcorre wrote:

 Do you mean something like:

 enum Foo { bar, baz }
 void fun(Foo foo) { }

 fun(baz);

 I don't really mind having to use switch/with but I've found myself
 wishing for the above on occasion.
Yes, but in Swift you need to prefix "baz" with a dot. -- /Jacob Carlborg
Dec 04 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-12-04 04:18, Steven Schveighoffer wrote:

 In D-speak, it looks like this:

 enum Foo
 {
     Bar,
     Baz
 }

 Foo foo;

 switch(foo)
 {
     case .Bar: // Foo is implied
     case .Baz:
 }

 void fun(Foo);

 fun(.Bar); // Foo is implied

 I don't think we could have this exact syntax, though.
I brought that up before, Walter doesn't like it. -- /Jacob Carlborg
Dec 03 2015
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 4 December 2015 at 03:18:02 UTC, Steven Schveighoffer 
wrote:
 The type system is static, and everything is done via 
 inference, which is very nice.
According to a swift dev I talked to, part of the algorithm is exponential and they have compile time problem because of this.
 Speed wise, I can't be sure. I'm sure others here have a better 
 understanding. All I've used it for so far is UI code on iOS. 
 Usability-wise, it's much easier to write swift than Objective 
 C.
I've seen all kind of numbers. It seems that there are a lot of feature that can be enabled/disabled, like overflow check, and it changes the performance profile quite a lot.
 One thing I would LOVE to see in D from swift is inference of 
 enum names.

 In D-speak, it looks like this:

 enum Foo
 {
    Bar,
    Baz
 }

 Foo foo;

 switch(foo)
 {
    case .Bar: // Foo is implied
    case .Baz:
 }

 void fun(Foo);

 fun(.Bar); // Foo is implied

 I don't think we could have this exact syntax, though.

 -Steve
switch(foo) with(Foo) { case Bar: case Baz: }
Dec 08 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/8/15 4:14 AM, deadalnix wrote:
 On Friday, 4 December 2015 at 03:18:02 UTC, Steven Schveighoffer wrote:
 The type system is static, and everything is done via inference, which
 is very nice.
According to a swift dev I talked to, part of the algorithm is exponential and they have compile time problem because of this.
Hm... I don't have the same problems.
 Speed wise, I can't be sure. I'm sure others here have a better
 understanding. All I've used it for so far is UI code on iOS.
 Usability-wise, it's much easier to write swift than Objective C.
I've seen all kind of numbers. It seems that there are a lot of feature that can be enabled/disabled, like overflow check, and it changes the performance profile quite a lot.
I would imagine that with all property (and virtual at that) functions for all class member variables, it can't be as performant in some cases, but I'm assuming in at least some cases the compiler inlines that away.
 One thing I would LOVE to see in D from swift is inference of enum names.

 In D-speak, it looks like this:

 enum Foo
 {
    Bar,
    Baz
 }

 Foo foo;

 switch(foo)
 {
    case .Bar: // Foo is implied
    case .Baz:
 }

 void fun(Foo);

 fun(.Bar); // Foo is implied

 I don't think we could have this exact syntax, though.
switch(foo) with(Foo) { case Bar: case Baz: }
Yes, again, that isn't the point. -Steve
Dec 08 2015
parent reply Chris Wright <dhasenan gmail.com> writes:
On Tue, 08 Dec 2015 08:38:23 -0500, Steven Schveighoffer wrote:

 On 12/8/15 4:14 AM, deadalnix wrote:
 On Friday, 4 December 2015 at 03:18:02 UTC, Steven Schveighoffer wrote:
 The type system is static, and everything is done via inference, which
 is very nice.
According to a swift dev I talked to, part of the algorithm is exponential and they have compile time problem because of this.
Hm... I don't have the same problems.
I'm guessing it's one of those situations where they have heuristics that normally shrink the problem space down to 3-4 options at most, and exponential costs at that point aren't so visible. But in some of their more strenuous test cases, I imagine, the heuristics can't chop down the problem space enough and they get code that takes minutes to compile.
Dec 08 2015
parent deadalnix <deadalnix gmail.com> writes:
On Tuesday, 8 December 2015 at 17:16:50 UTC, Chris Wright wrote:
 On Tue, 08 Dec 2015 08:38:23 -0500, Steven Schveighoffer wrote:

 On 12/8/15 4:14 AM, deadalnix wrote:
 On Friday, 4 December 2015 at 03:18:02 UTC, Steven 
 Schveighoffer wrote:
 The type system is static, and everything is done via 
 inference, which is very nice.
According to a swift dev I talked to, part of the algorithm is exponential and they have compile time problem because of this.
Hm... I don't have the same problems.
I'm guessing it's one of those situations where they have heuristics that normally shrink the problem space down to 3-4 options at most, and exponential costs at that point aren't so visible. But in some of their more strenuous test cases, I imagine, the heuristics can't chop down the problem space enough and they get code that takes minutes to compile.
I don't know swift well enough to tell you what are the problematic cases. However they seemed to think it was a serious issue and improving it is one of their primary goal for swift 3. Another one is getting the ABI nailed down.
Dec 08 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 4 December 2015 at 02:59:21 UTC, tcak wrote:
 On Thursday, 3 December 2015 at 20:37:04 UTC, Steven 
 Schveighoffer wrote:
 On 12/3/15 3:16 PM, Meta wrote:
 On Thursday, 3 December 2015 at 19:10:04 UTC, Steven 
 Schveighoffer wrote:
 And the lack of semi-colons has poisoned me from writing 
 syntactically
 valid lines in D :)
Surprisingly (or not), lack of semicolons is something that I have Ruby. There's a lot to be said for the little quality of life features in a language.
You may misunderstand -- I prefer semicolons. But having to write swift code for a few weeks, I find now when I write D code I forget them all the time (where usually my proper semi-colon rate is near 100%). -Steve
Since you have experience, what is the level of the language? Is it C or Javascript level? It is not clear by looking at example codes, and I do not have much time these days to try anything new. (My first post was written by looking at code examples.) Are you able to define C bindings? Can I do socket programming? Are Posix function accessible? How is the speed?
As opposed to D, there is a lot of conversion going on from C to Swift https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html#//apple_ref/doc/uid/TP40014216-CH8-XID_13 PS One hour of working with Lua ruin my semicolon discipline in D. And I am a semicolon man. First I type them in Lua, then I leave them out in D!
Dec 04 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 4 December 2015 at 10:24:48 UTC, Chris wrote:
 As opposed to D, there is a lot of conversion going on from C 
 to Swift
And they will have to keep converting, as there are breaking changes planned for Swift 3.0: https://github.com/apple/swift-evolution/blob/master/README.md Although I think that is rather nice, they admit that the language has added features too fast and are willing and hopefully able to clean it up because the feature set doesn't fit well together.
Dec 04 2015
prev sibling parent tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
On Friday, 4 December 2015 at 02:59:21 UTC, tcak wrote:
 On Thursday, 3 December 2015 at 20:37:04 UTC, Steven 
 Schveighoffer wrote:
 On 12/3/15 3:16 PM, Meta wrote:
 [...]
You may misunderstand -- I prefer semicolons. But having to write swift code for a few weeks, I find now when I write D code I forget them all the time (where usually my proper semi-colon rate is near 100%). -Steve
Since you have experience, what is the level of the language? Is it C or Javascript level? It is not clear by looking at example codes, and I do not have much time these days to try anything new. (My first post was written by looking at code examples.) Are you able to define C bindings? Can I do socket programming? Are Posix function accessible? How is the speed?
What I am seeing here is "import Glibc" (without semicolon at the end - pun intended). https://developer.ibm.com/swift/2015/12/03/introducing-the-ibm-swift-sandbox/
Dec 07 2015
prev sibling parent Kagamin <spam here.lot> writes:
On Thursday, 3 December 2015 at 17:56:49 UTC, tcak wrote:


 programmers are not aware of what things they are missing :D
Never needed typeof. Missing scope guards and needed static if once. On Thursday, 3 December 2015 at 20:16:50 UTC, Meta wrote:
 Surprisingly (or not), lack of semicolons is something that I 

 tried Ruby. There's a lot to be said for the little quality of 
 life features in a language.
LOL, I use semicolons in js and tsql, and I don't even know whether they are optional in css, I just put them in.
Dec 04 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-03 20:10, Steven Schveighoffer wrote:

 The truth is, swift is orders of magnitude better than Objective C.

 I have gotten used to the nullable API, though it sometimes seems more
 clunky than useful.
I find it very clunky as well. Sometimes it's too strict. I was a bit surprised when I noticed that converting from an integer to an enum returned an optional.
 Apple's API is still rather verbose and hard to discover, but that is not
swift's fault.
They could have gone the D route by separating the method name from the selector: extern(Objective-C) class Foo { void bar() selector("thisIsMyReallyLongSelector:withAnotherSelector:"); }
 And the lack of semi-colons has poisoned me from writing syntactically
 valid lines in D :)

 I miss D's algorithms and range API when working with swift. A lot. I've
 tried to use their sequence API, but it's very confusing.
I have not used it much, but I think it it's quite alright. But it's ridicule complicated to slice a string in Swift compared to D. One needs to pass in a range of a specific index type. var str = "Hello, playground" str.substringWithRange(Range<String.Index>(start: str.startIndex.advancedBy(2), end: str.endIndex.advancedBy(-1))) //"llo, playgroun" [1] One thing I really don't like in the D algorithms is "find". Instead of returning the actual element it returns the "rest" of the range. Although Swift doesn't even have "find" (as far as I can see) the use of optional types would be perfect here. [1] http://stackoverflow.com/a/24045156 -- /Jacob Carlborg
Dec 03 2015
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2015-12-04 07:51:32 +0000, Jacob Carlborg <doob me.com> said:

 On 2015-12-03 20:10, Steven Schveighoffer wrote:
 
 The truth is, swift is orders of magnitude better than Objective C.
 
 I have gotten used to the nullable API, though it sometimes seems more
 clunky than useful.
I find it very clunky as well. Sometimes it's too strict. I was a bit surprised when I noticed that converting from an integer to an enum returned an optional.
It's about preserving the invariants of the enum type, namely that it'll always have one of the allowed values. Append ! after the expression to unwrap the optional if you don't care about what happens when the value is invalid.
 Apple's API is still rather verbose and hard to discover, but that is 
 not swift's fault.
They could have gone the D route by separating the method name from the selector: extern(Objective-C) class Foo { void bar() selector("thisIsMyReallyLongSelector:withAnotherSelector:"); }
You can do that in Swift too with objc(some:selector:). And for Swift 3 they do plan to give Swift-specific names to pretty much all methods in the Apple frameworks. https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md And
 the lack of semi-colons has poisoned me from writing syntactically
 valid lines in D :)
 
 I miss D's algorithms and range API when working with swift. A lot. I've
 tried to use their sequence API, but it's very confusing.
I have not used it much, but I think it it's quite alright. But it's ridicule complicated to slice a string in Swift compared to D. One needs to pass in a range of a specific index type. var str = "Hello, playground" str.substringWithRange(Range<String.Index>(start: str.startIndex.advancedBy(2), end: str.endIndex.advancedBy(-1))) //"llo, playgroun"
You can be less verbose if you want: let str = "Hello, playground" str[str.startIndex.advancedBy(2) ..< str.endIndex.advancedBy(-1)] Also note that those special index types are actually iterators. You're decoding characters (grapheme clusters) as you advance those indexes.
 [...] Swift doesn't even have "find" (as far as I can see) the use of 
 optional types would be perfect here.
It's called indexOf. (Remember, the index type is an iterator.) It does return an optional. It will work for any type conforming to the ContainerType protocol where Element conforms to Equatable. Like this: let str = "Hello, playground" let start = str.unicodeScalars.indexOf("p")! let end = str.unicodeScalars.indexOf("g")! str.unicodeScalars[start ..< end] // "play" str.unicodeScalars[start ... end] // "playg" -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Dec 05 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-06 03:02, Michel Fortin wrote:

 Apple's API is still rather verbose and hard to discover, but that is
 not swift's fault.
They could have gone the D route by separating the method name from the selector: extern(Objective-C) class Foo { void bar() selector("thisIsMyReallyLongSelector:withAnotherSelector:"); }
You can do that in Swift too with objc(some:selector:).
But they (Apple) didn't choose to use that feature ;)
 And for Swift 3  they do plan to give Swift-specific names to pretty much all
methods in
 the Apple frameworks.
 https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md
Seems interesting.
 You can be less verbose if you want:

      let str = "Hello, playground"
      str[str.startIndex.advancedBy(2) ..< str.endIndex.advancedBy(-1)]
I tried that but couldn't make it to work. Not sure what I did wrong.
 Also note that those special index types are actually iterators.
Aha, I didn't know that.
 You're decoding characters (grapheme clusters) as you advance those indexes.
Not really what I needed, for me it would be enough with slicing the bytes.
 It's called indexOf. (Remember, the index type is an iterator.) It does
 return an optional. It will work for any type conforming to the
 ContainerType protocol where Element conforms to Equatable. Like this:

      let str = "Hello, playground"
      let start = str.unicodeScalars.indexOf("p")!
      let end = str.unicodeScalars.indexOf("g")!
      str.unicodeScalars[start ..< end] // "play"
      str.unicodeScalars[start ... end] // "playg"
I was looking for a method to return the first element matching a predicate. If it's an iterator I would expect to be able to get the value it points to. I can't see how I can do that with an Index in Swift. -- /Jacob Carlborg
Dec 06 2015
next sibling parent Daniel N <ufo orbiting.us> writes:
On Sunday, 6 December 2015 at 10:43:24 UTC, Jacob Carlborg wrote:
 Not really what I needed, for me it would be enough with 
 slicing the bytes.
I can't really test it, since I'm stuck on "Mavericks" and they stopped updating XCode. (last version before they destroyed the UI). But this should work, no? String(Array(str.characters)[1...2]) Guess now that it's open source I can finally play around with Swift2+ though.
Dec 06 2015
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2015-12-06 10:43:24 +0000, Jacob Carlborg <doob me.com> said:

 You're decoding characters (grapheme clusters) as you advance those indexes.
Not really what I needed, for me it would be enough with slicing the bytes.
That only works if the actual underlying representation is UTF8 (or other single-byte encoding). String abstracts that away from you. But you can do this if you want to work with bytes: let utf8View = str.utf8 utf8View[utf8View.startIndex.advancedBy(2) ..< utf8View.endIndex.advancedBy(-1)] or: let arrayOfBytes = Array(str.utf8) arrayOfBytes[2 ..< arrayOfBytes.count-1]
 It's called indexOf. (Remember, the index type is an iterator.) It does
 return an optional. It will work for any type conforming to the
 ContainerType protocol where Element conforms to Equatable. Like this:
 
      let str = "Hello, playground"
      let start = str.unicodeScalars.indexOf("p")!
      let end = str.unicodeScalars.indexOf("g")!
      str.unicodeScalars[start ..< end] // "play"
      str.unicodeScalars[start ... end] // "playg"
I was looking for a method to return the first element matching a predicate.
container.indexOf(predicate) container.indexOf { (element) in element == "p" } container.indexOf { $0 == "p" }
 If it's an iterator I would expect to be able to get the value it 
 points to. I can't see how I can do that with an Index in Swift.
container[index] The index is an iterator in the sense that it points at one location in the container and apply some container-released logic as you advance. But you still have to use the container to access its value. The index does not expose the value even when it knows about it internally. Not all index types are like that. Containers with random access normally use Int as their index type because it's sufficient and practical. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Dec 06 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-12-06 14:45, Michel Fortin wrote:

 That only works if the actual underlying representation is UTF8 (or
 other single-byte encoding). String abstracts that away from you. But
 you can do this if you want to work with bytes:

      let utf8View = str.utf8
      utf8View[utf8View.startIndex.advancedBy(2) ..<
 utf8View.endIndex.advancedBy(-1)]

 or:

      let arrayOfBytes = Array(str.utf8)
      arrayOfBytes[2 ..< arrayOfBytes.count-1]
All these just show that it's still too complicated ;)
      container.indexOf(predicate)
      container.indexOf { (element) in element == "p" }
      container.indexOf { $0 == "p" }

      container[index]
That's what I ended up doing. -- /Jacob Carlborg
Dec 06 2015
prev sibling parent Bubbasaur <bubba hotmail.com> writes:
Seems controversial:

https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md

Bubba.
Dec 04 2015