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