www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Apple introduces Swift as Objective-C sucessor

reply "Paulo Pinto" <pjmlp progtools.org> writes:
Just thought it would be nice to give a heads up about Apple's 
plans to replace Objective-C in the long run.

The language was presented today at the WWDC Keynote, looks like 
Ruby, uses ARC alongside the Objective-C runtime.

http://live.arstechnica.com/apples-wwdc-2014-keynote/

It also has a nice REPL experience, similar to Python's 
worksheets in IPython.

--
Paulo
Jun 02 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo

More information now made available https://developer.apple.com/swift/
Jun 02 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/2/2014 3:49 PM, Steven Schveighoffer wrote:
 On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org>
 wrote:
 More information now made available

 https://developer.apple.com/swift/

"Memory is managed automatically, and you don’t even need to type semi-colons." ...

Heh, yea, that's the #1 thing that jumped out at me as well. Sounds like it probably sums up a lot about the language. The whole thing sounds like "We love how JS and Python allow mediocre programmers to churn out bad software quickly, but since we *are* Apple and love strategic lock-in just as much as MS, here's our own goofy version of the exact same thing that we're going to push instead."
Jun 02 2014
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/02/2014 11:15 PM, Steven Schveighoffer wrote:
 They have template constraints similar to D. It looks something like this:

 func foo<T where T == Int>(t: T)

 I think everything after the where can be some condition, but I don't
 know how expressive that is. The examples aren't very telling.
 ...

https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GenericParametersAndArguments.html#//apple_ref/doc/uid/TP40014097-CH37-XID_774 You can have subtype and equality constraints on generic type parameter and their "associated types".
 I still haven't figured out whether generics are runtime-based or
 compile-time based.

It is actual parametric polymorphism and not a form of macro if that is what you mean. I.e. the declaration is type checked only once.
 But some form of generics will be very nice to have.

Jun 02 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/02/2014 10:23 PM, Nick Sabalausky wrote:
 On 6/2/2014 3:49 PM, Steven Schveighoffer wrote:
 On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org>
 wrote:
 More information now made available

 https://developer.apple.com/swift/

"Memory is managed automatically, and you don’t even need to type semi-colons." ...

Heh, yea, that's the #1 thing that jumped out at me as well. Sounds like it probably sums up a lot about the language. ...

Well, it's a sales pitch. I skipped right to the language reference, but there seemed nothing to be there that would support the statement "Swift is the result of the latest research on programming languages," But more annoyingly, "Syntax is tuned to make it easy to define your intent — for example, simple three-character keywords define a variable (var) or constant (let)." i.e. Swift is another language that is confused about what 'variable' and 'constant' mean.
 The whole thing sounds like "We love how JS and Python allow mediocre
 programmers to churn out bad software quickly, but since we *are* Apple
 and love strategic lock-in just as much as MS, here's our own goofy
 version of the exact same thing that we're going to push instead."

It is typed.
Jun 02 2014
prev sibling parent reply Byron Heads <byron.heads gmail.com> writes:
On 2014-06-02 19:45:28 +0000, Paulo Pinto said:

 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's plans to 
 replace Objective-C in the long run.
 
 The language was presented today at the WWDC Keynote, looks like Ruby, 
 uses ARC alongside the Objective-C runtime.
 
 http://live.arstechnica.com/apples-wwdc-2014-keynote/
 
 It also has a nice REPL experience, similar to Python's worksheets in IPython.
 
 --
 Paulo

More information now made available https://developer.apple.com/swift/

"Use .. to make a range that omits its upper value, and use ... to make a range that includes both values." That is going to be a source of a lot of bugs, so easy to type 3 when you ment 2
Jun 03 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-06-03 15:18, Byron Heads wrote:

 "Use .. to make a range that omits its upper value, and use ... to make
 a range that includes both values."

 That is going to be a source of a lot of bugs, so easy to type 3 when
 you ment 2

Same as with Ruby ... but the other way around :) -- /Jacob Carlborg
Jun 03 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org>  =

wrote:

 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's plans =


 replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks like Ruby=


 uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's worksheets in=


 IPython.

 --
 Paulo

More information now made available https://developer.apple.com/swift/

"Memory is managed automatically, and you don=E2=80=99t even need to typ= e = semi-colons." ... -Steve
Jun 02 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 2 June 2014 at 19:45:29 UTC, Paulo Pinto wrote:
 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo

More information now made available https://developer.apple.com/swift/

Manual now visible https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2
Jun 02 2014
prev sibling next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2

Same mistake with syntatically ambiguous template syntax.
Jun 02 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Monday, 2 June 2014 at 20:07:00 UTC, Nordlöw wrote:
 https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2

 Same mistake with syntatically ambiguous template syntax.

Maybe the deprecated that pesky less than operator.
Jun 02 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Monday, 2 June 2014 at 19:45:29 UTC, Paulo Pinto wrote:
 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo

More information now made available https://developer.apple.com/swift/

- "Closures unified with function pointers" - "Tuples and multiple return values" Sounds pretty neat, but I can't stand that horrid opening brace placement. It's something I really hate about Scala as well. balloonConfigurator = { b in //... }
Jun 02 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 2 June 2014 at 20:07:00 UTC, Nordlöw wrote:
 https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2

 Same mistake with syntatically ambiguous template syntax.

Actually I find it better on my eyes, than D's one. Maybe too many years reading C++, Java and C# code. -- Paulo
Jun 02 2014
prev sibling next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 Maybe the deprecated that pesky less than operator.

Funny :)
Jun 02 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 02 Jun 2014 15:19:26 -0400, Paulo Pinto <pjmlp progtools.org>  
wrote:

 Just thought it would be nice to give a heads up about Apple's plans to  
 replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks like Ruby,  
 uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's worksheets in  
 IPython.

Uses same syntax for array literals as D. This is very nice, I hate how arrays are created in Objective C. -Steve
Jun 02 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jun 02, 2014 at 08:37:30PM +0000, Paulo Pinto via Digitalmars-d wrote:
 On Monday, 2 June 2014 at 20:07:00 UTC, Nordlw wrote:
https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2

Same mistake with syntatically ambiguous template syntax.

Actually I find it better on my eyes, than D's one. Maybe too many years reading C++, Java and C# code.

Argh! I have also spent many years reading C++ template code... but I still utterly hate using <> as template argument list delimiters. Not only it makes my eyes bleed, it's also ambiguous and leads to lexers that must parse before they can lex. Ugh!! (Now that's not to say D's template syntax is perfect either... things like func(A...)(B...) where A... and B... are long argument lists, are also very taxing to read because when you first start scanning the declaration, it's hard to tell whether the A... are compile-time arguments or runtime-arguments. But nevertheless, I think D's syntax is WAY saner than anything based on C++'s horrific <>'s.) T -- Democracy: The triumph of popularity over principle. -- C.Bond
Jun 02 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jun 02, 2014 at 04:23:47PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
 On 6/2/2014 3:49 PM, Steven Schveighoffer wrote:
On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org>
wrote:
More information now made available

https://developer.apple.com/swift/

"Memory is managed automatically, and you don’t even need to type semi-colons." ...

Heh, yea, that's the #1 thing that jumped out at me as well. Sounds like it probably sums up a lot about the language. The whole thing sounds like "We love how JS and Python allow mediocre programmers to churn out bad software quickly, but since we *are* Apple and love strategic lock-in just as much as MS, here's our own goofy version of the exact same thing that we're going to push instead."

Seems everyone is fixating on semicolons, but seriously, am I the only one who sees the elephant in the room? Automatic memory management!!! Where's Manu and his GC tirades when you need him? ;-) T -- Don't throw out the baby with the bathwater. Use your hands...
Jun 02 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 02 Jun 2014 17:00:40 -0400, H. S. Teoh via Digitalmars-d  =

<digitalmars-d puremagic.com> wrote:

 On Mon, Jun 02, 2014 at 04:23:47PM -0400, Nick Sabalausky via  =

 Digitalmars-d wrote:
 On 6/2/2014 3:49 PM, Steven Schveighoffer wrote:
On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org=


wrote:
More information now made available

https://developer.apple.com/swift/

"Memory is managed automatically, and you don=E2=80=99t even need to=



semi-colons."

...

Heh, yea, that's the #1 thing that jumped out at me as well. Sounds like it probably sums up a lot about the language. The whole thing sounds like "We love how JS and Python allow mediocre=


 programmers to churn out bad software quickly, but since we *are*
 Apple and love strategic lock-in just as much as MS, here's our own
 goofy version of the exact same thing that we're going to push
 instead."

Seems everyone is fixating on semicolons, but seriously, am I the only=

 one who sees the elephant in the room? Automatic memory management!!!
 Where's Manu and his GC tirades when you need him? ;-)

It will be ARC. Same as Objective C. But I don't like that the memory management is automatic. More likely th= an = not, it will allocate things you don't want it to, or could avoid if you= = had manual control. I'm skimming the book about this new language, and i= t = certainly will be more D-like than Objective C, which is nice, but there= = are some things that I really don't like. Significant whitespace is one = of = them. They have template constraints similar to D. It looks something like thi= s: func foo<T where T =3D=3D Int>(t: T) I think everything after the where can be some condition, but I don't kn= ow = how expressive that is. The examples aren't very telling. I still haven't figured out whether generics are runtime-based or = compile-time based. But some form of generics will be very nice to have.= -Steve
Jun 02 2014
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo

I like how the lambdas can omit the parameters then reference them by special $0, $1, etc (e.g., { $0 < $1 }). It reminds me of our string lambdas ("a < b") in brevity without the hacky feel those had. As much as I like the new lambda syntax I still miss how short string lambdas could be. arr.sort!"a < b"(); arr.sort!((a, b) => a < b); Maybe something like... arr.sort!( => $0 < $1 ) ...could be supported. Not a huge improvement but I like it anyway.
Jun 02 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/2/2014 3:03 PM, Brad Anderson wrote:
 I like how the lambdas can omit the parameters then reference them by special
 $0, $1, etc (e.g., { $0 < $1 }).

We had something similar years ago, to support regexes, and people hated it so I reverted it.
Jun 02 2014
prev sibling next sibling parent reply "ponce" <contact gam3esfrommars.fr> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo

My thoughts while browsing the site: - function-leve type inference much like Rust - no constness in the type-system (I like it) - class are reference types, structs are values types, much like D and C# - runtime dispacthed OO interfaces called "protocols". Blend the difference between runtime or compile-time polymorphism. Classes, structs and enums can implement a protocol. Available as first class runtime values, so the protocol dispatch will be slow like in Golang. - enumerations are much like Ocaml ADT, can be parameterized by a tuple of values, value types, recursive definitions - worrying focus on properties. - strange closure syntax - optional chaining, another anti-feature in my eyes - normal arithmetic operator throw a trap on integer overflow (!). This must be incredibly slow. - looks like Array is a fat slice to a reference-counted array - operator overloading is in, supercharged with custom operator, custom precedence (!?) - builtin tuples syntax - break with C integer promotion, like Rust. - I haven't seen pointers - convenience is a keyword!
Jun 02 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/2/2014 4:13 PM, Messenger wrote:
 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?

segfault

Best comment yet! ROFL
Jun 02 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/3/2014 5:03 AM, Chris wrote:
 After all it was created by God, er, Apple. (Mind you, it was
 because of an apple that God evicted humans from paradaise :-)

Heh heh :) Why has that never occurred to me before? Side note: I've heard arguments that the biblical "apple" may have originally been a pomegranate. If so, then not surprising it would have been changed to an apple - pomegranates had kinda gotten lost from public awareness in certain cultures (like the US) until only fairly recently with all the renewed interest in healthy eating. (Not that apples aren't healthy, but poms are said to be *really* healthy, apparently.)
Jun 03 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/3/2014 1:34 PM, Jonathan M Davis via Digitalmars-d wrote:
 Technically, all it's ever referred to is as "fruit" or the "forbidden fruit"
 - and it's the fruit of one very specific tree which only existed in the
 Garden of Eden. So, arguably associating it with any fruit currently in
 existence is a bit of a misnomer. So, it shouldn't have any effect on your
 fruit dietary choices. ;)

Well, it wouldn't affect my diet anyway: I generally try to avoid eating *any* fruit (or other food) that's served by a serpent, or by any other non-humanoid that isn't a vending machine. :) I figure it's just the prudent thing to do. Yup.
Jun 03 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-06-03 01:01, deadalnix wrote:

 How do they do error handling ?

Objective-C does support exceptions, but libraries like Cocoa avoids throwing exceptions and leave those to the user (developer). Instead it usually returns a bool to indicate success or failure and then provides an NSError instance via an out parameter. -- /Jacob Carlborg
Jun 03 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/3/2014 2:44 PM, Remo wrote:
 No exceptions (!) so this is at least something that this
 language do better as C++ and D  :D
 Not everyone think that exceptions are necessary or there is no
 other way to handle errors.

Exceptions make ARC expensive, so this may be a reasonable decision for Swift. Exceptions and GC go together like chocolate and coffee :-)
Jun 04 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-06-05 11:04, Russel Winder via Digitalmars-d wrote:

 This is very much the Java model: exceptions are for exceptional events
 that can be handled or not.

 In Python of course exceptions are just control flow.

Ruby has both "raise", for exceptions, and "throw", for control flow. But I suspect they're both implemented exactly the same. -- /Jacob Carlborg
Jun 05 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-06-04 23:21, Walter Bright wrote:
 On 6/3/2014 2:44 PM, Remo wrote:
 No exceptions (!) so this is at least something that this
 language do better as C++ and D  :D
 Not everyone think that exceptions are necessary or there is no
 other way to handle errors.

Exceptions make ARC expensive, so this may be a reasonable decision for Swift.

I'm wondering how they'll handle exceptions thrown from Objective-C code which Swift calls. -- /Jacob Carlborg
Jun 05 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-06-05 19:14, Remo wrote:

 Exceptions make a lot of other thing expensive and complicated.
 IMHO Exceptions should only be used in really really exceptional cases
 and not all the way and for control flow.

 Fortunately it is not really necessary to use Exceptions in C++.
 A great example for this is LLVM and Clang code base.

Even if you don't have to use exceptions, the language (Objective-C) does support them and someone will use them. -- /Jacob Carlborg
Jun 05 2014
prev sibling next sibling parent "ponce" <contact gam3esfrommars.fr> writes:
 My thoughts while browsing the site:
 - function-leve type inference much like Rust
 - no constness in the type-system (I like it)
 - class are reference types, structs are values types, much 
 like D and C#
 - runtime dispacthed OO interfaces called "protocols". Blend 
 the difference between runtime or compile-time polymorphism. 
 Classes, structs and enums can implement a protocol. Available 
 as first class runtime values, so the protocol dispatch will be 
 slow like in Golang.
 - enumerations are much like Ocaml ADT, can be parameterized by 
 a tuple of values, value types, recursive definitions
 - worrying focus on properties.
 - strange closure syntax
 - optional chaining, another anti-feature in my eyes
 - normal arithmetic operator throw a trap on integer overflow 
 (!). This must be incredibly slow.
 - looks like Array is a fat slice to a reference-counted array
 - operator overloading is in, supercharged with custom 
 operator, custom precedence (!?)
 - builtin tuples syntax
 - break with C integer promotion, like Rust.
 - I haven't seen pointers
 - convenience is a keyword!

- no exceptions (!) - unsigned integers; check - type inference is "bidirectional by expression or statement" - class have deterministic destructors, structs have no destructors; like D except reversed - It seems the only RAII source is through RC and classes. - no single root class
Jun 02 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?
 - type inference is "bidirectional by expression or statement"

KAMOULOX ! (french people will understand)
Jun 02 2014
prev sibling next sibling parent "ponce" <contact gam3esfrommars.fr> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?

I guess error codes, a proven technology! The lack of exceptions put this language firmly in the "irrelevant" bracket. Add that "goto" isn't here and the only way to release resources on error path is to use RC-managed classes, you can bet the cleanup lines will be numerous and frequently forgotten.
Jun 02 2014
prev sibling next sibling parent "Messenger" <dont shoot.me> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?

segfault
Jun 02 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?
 - type inference is "bidirectional by expression or statement"

KAMOULOX ! (french people will understand)

It specifically says that the language has optional types, e.g., Maybe or Option. I don't know if they're a part of the ADT feature or something separate, maybe some syntax sugar like C#'s ?.
Jun 02 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 2 June 2014 at 23:12:15 UTC, ponce wrote:
 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?

I guess error codes, a proven technology!

Well, for sure it is proven :D It is proven to never be checked !
 The lack of exceptions put this language firmly in the 
 "irrelevant" bracket.

I wouldn't do it that fast. I mean it is apple. You just had to see the look in the eyes of peoples during the keynote. They were listening to god itself. Apple could pull anything and would be using it. And quite frankly it can't be worse than Objective C, so people will be using on iOS.
Jun 02 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Tuesday, 3 June 2014 at 00:06:15 UTC, Walter Bright wrote:
 On 6/2/2014 3:03 PM, Brad Anderson wrote:
 I like how the lambdas can omit the parameters then reference 
 them by special
 $0, $1, etc (e.g., { $0 < $1 }).

We had something similar years ago, to support regexes, and people hated it so I reverted it.

It's a step down the slippery slope of things that made Scala not as good as it could have been.
Jun 02 2014
prev sibling next sibling parent "Chris Cain" <zshazz gmail.com> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?

I haven't read too much into Swift but languages with ADTs, pattern matching, and no exceptions can (and usually do) return using an ADT looking something like (pseudocode): adt Outcome(T) { Error(ErrorType e); Success(T result); } and then for a "try catch" type block, you do things with switches switch(http.getResponse(someServer)) { case Success(r): // ... use r case Error(http.error.Http404(msg)): // handle the 404 error case Error(e): return Error(e); // Let the caller handle it } Or some other similar construct. With macros you can easily write something that tries to get the outcome's success and if it can't, then it automagically returns the error for you, throwing the error to the calling function like you expect from exceptions. That said, if you're paying attention you'll see the similarity to checked exceptions... So basically, those two features give you what is effectively exception handling, "nothrow", and so on. It's one of those really powerful language features with a lot of leverage that makes it easy to define constructs in the language instead of the compiler.
Jun 02 2014
prev sibling next sibling parent "AsmMan" <lol.themask gmail.com> writes:
On Tuesday, 3 June 2014 at 00:06:15 UTC, Walter Bright wrote:
 On 6/2/2014 3:03 PM, Brad Anderson wrote:
 I like how the lambdas can omit the parameters then reference 
 them by special
 $0, $1, etc (e.g., { $0 < $1 }).

We had something similar years ago, to support regexes, and people hated it so I reverted it.

Well-done. It's really ugly. I hate it.
Jun 02 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?

With optional types like in most FP languages. The language needs to keep compatibility with the Objective-C runtime, and Objective-C exceptions never worked across all scenarios. Just check the Objective-C and Cocoa documentation about possible caveats. -- Paulo
Jun 02 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
ponce:

 - normal arithmetic operator throw a trap on integer overflow 
 (!). This must be incredibly slow.

My experience in ObjectPascal tells me that this limited loss of performance is quite acceptable when you debug the code or in routines that don't need the max performance. So it's similar to D array bound checks. In some functions (like the safe ones in D) you can even decide to keep it on. So I like checked arithmetic by default if there are ways to disable suck checks in specific functions/parts. The good Graydon (one of the main designers of Rust) has written some quick notes on Swift: http://graydon2.dreamwidth.org/5785.html Currently Reddit-Programming is buzzing a lot about Swift. Bye, bearophile
Jun 03 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Tuesday, 3 June 2014 at 00:57:53 UTC, Chris Cain wrote:
 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?

I haven't read too much into Swift but languages with ADTs, pattern matching, and no exceptions can (and usually do) return using an ADT looking something like (pseudocode): adt Outcome(T) { Error(ErrorType e); Success(T result); } and then for a "try catch" type block, you do things with switches switch(http.getResponse(someServer)) { case Success(r): // ... use r case Error(http.error.Http404(msg)): // handle the 404 error case Error(e): return Error(e); // Let the caller handle it } Or some other similar construct. With macros you can easily write something that tries to get the outcome's success and if it can't, then it automagically returns the error for you, throwing the error to the calling function like you expect from exceptions. That said, if you're paying attention you'll see the similarity to checked exceptions... So basically, those two features give you what is effectively exception handling, "nothrow", and so on. It's one of those really powerful language features with a lot of leverage that makes it easy to define constructs in the language instead of the compiler.

Ocaml and Haskell also have ADT and exhaustive matching. Yet Ocaml provides exceptions. Haskell provide the Exception monad to avoid littering the code with error-checking. Of course ADT are great and all but if error checking is verbose it won't encourage people to check for errors.
Jun 03 2014
prev sibling next sibling parent "renoX" <renozyx gmail.com> writes:
On Monday, 2 June 2014 at 22:11:15 UTC, ponce wrote:
[cut]
 - normal arithmetic operator throw a trap on integer overflow 
 (!). This must be incredibly slow.

Well, Apple make their own CPU, so maybe they plan to add 'trap on integer overflow' operation to the CPU? The most difficult part is finding where to put the 'trap on overflow' bit in the ISA, the implementation is nearly free.. renoX
Jun 03 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Monday, 2 June 2014 at 23:54:27 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 23:12:15 UTC, ponce wrote:
 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?

I guess error codes, a proven technology!

Well, for sure it is proven :D It is proven to never be checked !
 The lack of exceptions put this language firmly in the 
 "irrelevant" bracket.

I wouldn't do it that fast. I mean it is apple. You just had to see the look in the eyes of peoples during the keynote. They were listening to god itself. Apple could pull anything and would be using it.

Yep. I'm sure that all Apple fanboys & girls will hail it as _the ultimate_ super-hyper-mega-language of the century, ah, of the millenium. After all it was created by God, er, Apple. (Mind you, it was because of an apple that God evicted humans from paradaise :-)
 And quite frankly it can't be worse than Objective C, so people
 will be using on iOS.

Well, Objective C does its job, nothing special. It's not a great language but a reliable tool. I haven't used it for years now but I'm sure I would miss the powerful feartures of D, if I used it now.
Jun 03 2014
prev sibling next sibling parent "Chris Cain" <zshazz gmail.com> writes:
On Tuesday, 3 June 2014 at 08:33:14 UTC, ponce wrote:
 On Tuesday, 3 June 2014 at 00:57:53 UTC, Chris Cain wrote:
 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 - no exceptions (!)

How do they do error handling ?

I haven't read too much into Swift but languages with ADTs, pattern matching, and no exceptions can (and usually do) return using an ADT

Ocaml and Haskell also have ADT and exhaustive matching. Yet Ocaml provides exceptions. Haskell provide the Exception monad to avoid littering the code with error-checking. Of course ADT are great and all but if error checking is verbose it won't encourage people to check for errors.

Of course not all languages with ADT and pattern matching have no exceptions. But the ones that don't have exceptions get by using the process I described. And verbosity is usually taken care of (somewhat) well with macros if the language supports them. But yes, like I stated, it usually feels similar to a system with checked exceptions, which has the natural problem of "not encouraging people to check for errors." So I'm not going to suggest it's the perfect way, but it is quite impressive how the features added together can accomplish so much.
Jun 03 2014
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo

"Thank God!!" I told my colleagues today when they told me about it. Swift is like 10x better langauge than that abomination called "Objective-C".
Jun 03 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/3/2014 7:10 AM, Dejan Lekic wrote:
 "Thank God!!" I told my colleagues today when they told me about it.
 Swift is like 10x better langauge than that abomination called
 "Objective-C".

You know, my first impression of Swift was "ugh, a 'me too' JS/Python-like language...", but I admit, the algebraic types, ARC and generics have my attention now. It's no D, but how many languages have even half-way decent generics, let alone that plus algebraics? My only opinion of ObjC is "I've never quite been able to understand it". So Swift does, at the very least, seem like it may be a notable improvement.
Jun 03 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 3 June 2014 at 11:10:43 UTC, Dejan Lekic wrote:
 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo

"Thank God!!" I told my colleagues today when they told me about it. Swift is like 10x better langauge than that abomination called "Objective-C".

I kind of liked it back in 1999, when I had to port a Particle Engine from Objective-C/NeXT to C++/Windows. However after so many languages in my toolbox, I would have to agree to the language's many warts. -- Paulo
Jun 03 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 02 Jun 2014 18:03:43 -0400, Brad Anderson <eco gnuk.net> wrote:

 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's plans to  
 replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks like Ruby,  
 uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's worksheets in  
 IPython.

 --
 Paulo

I like how the lambdas can omit the parameters then reference them by special $0, $1, etc (e.g., { $0 < $1 }). It reminds me of our string lambdas ("a < b") in brevity without the hacky feel those had. As much as I like the new lambda syntax I still miss how short string lambdas could be. arr.sort!"a < b"(); arr.sort!((a, b) => a < b); Maybe something like... arr.sort!( => $0 < $1 ) ...could be supported. Not a huge improvement but I like it anyway.

I think just $0 < $1 could infer the fact that it is a lambda, as this is not currently valid syntax. I would like that too. -Steve
Jun 03 2014
prev sibling next sibling parent "Chris Cain" <zshazz gmail.com> writes:
On Tuesday, 3 June 2014 at 13:18:38 UTC, Byron Heads wrote:
 "Use .. to make a range that omits its upper value, and use ... 
 to make a range that includes both values."

 That is going to be a source of a lot of bugs, so easy to type 
 3 when you ment 2

Agreed. But I think if the language made it differentiate better, having exclusive and inclusive versions could work... inclusive: 0...8 exclusive: 0..<9 Personally, when I'm writing out pseudocode I almost always use "..<" because it's obvious and no one has ever wondered "What do you mean by that?" I've heard a few times from people that wanted to clarify whether I meant inclusive or exclusive by "0..9"
Jun 03 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

Thanks for sharing, Swift looks good on the surface! Remains to see how well the dev environment is, but I guess this will kill a lot of the scripting platforms on iOS. I look forward to do some iOS apps now, at least if it interops well with C++. (Does it?) Ola.
Jun 03 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 03.06.2014 16:34, schrieb "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>":
 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's plans
 to replace Objective-C in the long run.

Thanks for sharing, Swift looks good on the surface! Remains to see how well the dev environment is, but I guess this will kill a lot of the scripting platforms on iOS. I look forward to do some iOS apps now, at least if it interops well with C++. (Does it?) Ola.

You need to provide an Objective-C or C wrapper. https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/index.html#//apple_ref/doc/uid/TP40014216 -- Paulo
Jun 03 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-06-03 17:27, Paulo Pinto wrote:

 You need to provide an Objective-C or C wrapper.

Or a D wrapper ;) -- /Jacob Carlborg
Jun 03 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 03, 2014 at 01:05:24PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
 On 6/3/2014 5:03 AM, Chris wrote:
After all it was created by God, er, Apple. (Mind you, it was
because of an apple that God evicted humans from paradaise :-)

Heh heh :) Why has that never occurred to me before? Side note: I've heard arguments that the biblical "apple" may have originally been a pomegranate. If so, then not surprising it would have been changed to an apple - pomegranates had kinda gotten lost from public awareness in certain cultures (like the US) until only fairly recently with all the renewed interest in healthy eating. (Not that apples aren't healthy, but poms are said to be *really* healthy, apparently.)

Note that NOWHERE in the original Hebrew Bible does it say that the fruit was an apple or a pomegranate or anything like that. The apple/pomegranate interpretation is entirely made up, probably by an overly enthusiastic children's story author. T -- Shin: (n.) A device for finding furniture in the dark.
Jun 03 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 03 Jun 2014 13:05:24 -0400
Nick Sabalausky via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 6/3/2014 5:03 AM, Chris wrote:
 After all it was created by God, er, Apple. (Mind you, it was
 because of an apple that God evicted humans from paradaise :-)

Heh heh :) Why has that never occurred to me before? Side note: I've heard arguments that the biblical "apple" may have originally been a pomegranate. If so, then not surprising it would have been changed to an apple - pomegranates had kinda gotten lost from public awareness in certain cultures (like the US) until only fairly recently with all the renewed interest in healthy eating. (Not that apples aren't healthy, but poms are said to be *really* healthy, apparently.)

Technically, all it's ever referred to is as "fruit" or the "forbidden fruit" - and it's the fruit of one very specific tree which only existed in the Garden of Eden. So, arguably associating it with any fruit currently in existence is a bit of a misnomer. So, it shouldn't have any effect on your fruit dietary choices. ;) - Jonathan M Davis
Jun 03 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Tuesday, 3 June 2014 at 20:26:52 UTC, Jacob Carlborg wrote:
 On 2014-06-03 01:01, deadalnix wrote:

 How do they do error handling ?

Objective-C does support exceptions, but libraries like Cocoa avoids throwing exceptions and leave those to the user (developer). Instead it usually returns a bool to indicate success or failure and then provides an NSError instance via an out parameter.

Writing messages which set errors like that was always weird. // The pointer needs to use __autoreleasing so it captures the correct // reference semantics. - (BOOL) doSomethingWithError:(NSError* __autoreleasing * error) { // You must set to nil, as Objective C won't initialise to nil implicitly. NSError* otherError = nil; // Pass pointer to object in a C-like way. [foo doSomethingElseWithError:&otherError]; // We have to check that the out param is not nil. if (error && otherError) { *error = otherError; // We return a boolean flag for those people who // don't capture the error itself but want a convenient // if([foo doSomethingWithError:nil] == NO) return NO; } return YES; } What does this look like if you use exceptions instead in a saner language? void doSomething() { doSomethingElse(); } Oh! Right!
Jun 03 2014
prev sibling next sibling parent "Remo" <remo4d gmail.com> writes:
On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
 My thoughts while browsing the site:
 - function-leve type inference much like Rust
 - no constness in the type-system (I like it)
 - class are reference types, structs are values types, much 
 like D and C#
 - runtime dispacthed OO interfaces called "protocols". Blend 
 the difference between runtime or compile-time polymorphism. 
 Classes, structs and enums can implement a protocol. Available 
 as first class runtime values, so the protocol dispatch will 
 be slow like in Golang.
 - enumerations are much like Ocaml ADT, can be parameterized 
 by a tuple of values, value types, recursive definitions
 - worrying focus on properties.
 - strange closure syntax
 - optional chaining, another anti-feature in my eyes
 - normal arithmetic operator throw a trap on integer overflow 
 (!). This must be incredibly slow.
 - looks like Array is a fat slice to a reference-counted array
 - operator overloading is in, supercharged with custom 
 operator, custom precedence (!?)
 - builtin tuples syntax
 - break with C integer promotion, like Rust.
 - I haven't seen pointers
 - convenience is a keyword!

- no exceptions (!) - unsigned integers; check - type inference is "bidirectional by expression or statement" - class have deterministic destructors, structs have no destructors; like D except reversed - It seems the only RAII source is through RC and classes. - no single root class

No exceptions (!) so this is at least something that this language do better as C++ and D :D Not everyone think that exceptions are necessary or there is no other way to handle errors. But if there is no RAII and only automatic memory management then it is very bad.
Jun 03 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo

It appears they still have aways to go with the ARC implementation: http://www.splasmata.com/?p=2798 HN discussion: http://www.splasmata.com/?p=2798 It's going to be very interesting to see how good they can get it though. As far as I know, Apple has the most experience with ARC and they certainly have the brainpower to push it to its limits.
Jun 04 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 5 June 2014 at 03:12:05 UTC, Brad Anderson wrote:
 HN discussion: http://www.splasmata.com/?p=2798

That should be https://news.ycombinator.com/item?id=7849213
Jun 04 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-06-04 at 14:21 -0700, Walter Bright via Digitalmars-d
wrote:
 On 6/3/2014 2:44 PM, Remo wrote:
 No exceptions (!) so this is at least something that this
 language do better as C++ and D  :D
 Not everyone think that exceptions are necessary or there is no
 other way to handle errors.

Exceptions make ARC expensive, so this may be a reasonable decision for Swift. Exceptions and GC go together like chocolate and coffee :-)

I think Pike, Cox, et al. disagree; for them exceptions are only a termination mechanism and return codes are the way of communicating. If Swift has no exceptions, then Apple must be following the Go model rather than the D, Python, (C++ ?), etc. one. I am still trying to work out what Rust conditions really are: they language of exceptions is used but there is no stack unwinding. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 04 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 5 June 2014 at 03:15:53 UTC, Brad Anderson wrote:
 On Thursday, 5 June 2014 at 03:12:05 UTC, Brad Anderson wrote:
 HN discussion: http://www.splasmata.com/?p=2798

That should be https://news.ycombinator.com/item?id=7849213

 Turns out, at least 82.9% of it was just swift_retain / 
 swift_release (ref counting).

Probably interlocked arithmetic.
Jun 04 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 5 June 2014 at 03:15:53 UTC, Brad Anderson wrote:
 On Thursday, 5 June 2014 at 03:12:05 UTC, Brad Anderson wrote:
 HN discussion: http://www.splasmata.com/?p=2798

That should be https://news.ycombinator.com/item?id=7849213

Also they said they don't use ARC in objc for performance, so it's not that fast, I suppose.
Jun 04 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 June 2014 at 04:35:18 UTC, Russel Winder via 
Digitalmars-d wrote:
 I am still trying to work out what Rust conditions really are: 
 they
 language of exceptions is used but there is no stack unwinding.

You may want to look at LISP. This mechanism is not new to Rust (abeit, it has its specificities, but the idea is the same). It allow the caller to plug some code where the error handling take place. It it doesn't, then an exception is thrown. I proposed conditions for D a while ago, but didn't got much traction :(
Jun 04 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 June 2014 at 05:49:17 UTC, deadalnix wrote:
 On Thursday, 5 June 2014 at 04:35:18 UTC, Russel Winder via 
 Digitalmars-d wrote:
 I am still trying to work out what Rust conditions really are: 
 they
 language of exceptions is used but there is no stack unwinding.

You may want to look at LISP. This mechanism is not new to Rust (abeit, it has its specificities, but the idea is the same). It allow the caller to plug some code where the error handling take place. It it doesn't, then an exception is thrown. I proposed conditions for D a while ago, but didn't got much traction :(

http://web.mit.edu/rust-lang_v0.8/doc/tutorial-conditions.html
Jun 04 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 5 June 2014 at 04:35:18 UTC, Russel Winder via 
Digitalmars-d wrote:
 I think Pike, Cox, et al. disagree; for them exceptions are 
 only a
 termination mechanism and return codes are the way of 
 communicating. If
 Swift has no exceptions, then Apple must be following the Go 
 model
 rather than the D, Python, (C++ ?), etc. one.

It seems interesting to note that for M# it's the exact reverse, exceptions are for recoverable errors and crashing is for unrecoverable ones (I lost the link to the reference).
Jun 05 2014
prev sibling next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2014-06-05 at 07:13 +0000, ponce via Digitalmars-d wrote:
 On Thursday, 5 June 2014 at 04:35:18 UTC, Russel Winder via 
 Digitalmars-d wrote:
 I think Pike, Cox, et al. disagree; for them exceptions are 
 only a
 termination mechanism and return codes are the way of 
 communicating. If
 Swift has no exceptions, then Apple must be following the Go 
 model
 rather than the D, Python, (C++ ?), etc. one.

It seems interesting to note that for M# it's the exact reverse, exceptions are for recoverable errors and crashing is for unrecoverable ones (I lost the link to the reference).

This is very much the Java model: exceptions are for exceptional events that can be handled or not. In Python of course exceptions are just control flow. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 05 2014
prev sibling parent "Remo" <remo4d gmail.com> writes:
On Thursday, 5 June 2014 at 09:55:21 UTC, Jacob Carlborg wrote:
 On 2014-06-04 23:21, Walter Bright wrote:
 On 6/3/2014 2:44 PM, Remo wrote:
 No exceptions (!) so this is at least something that this
 language do better as C++ and D  :D
 Not everyone think that exceptions are necessary or there is 
 no
 other way to handle errors.

Exceptions make ARC expensive, so this may be a reasonable decision for Swift.

I'm wondering how they'll handle exceptions thrown from Objective-C code which Swift calls.

Exceptions make a lot of other thing expensive and complicated. IMHO Exceptions should only be used in really really exceptional cases and not all the way and for control flow. Fortunately it is not really necessary to use Exceptions in C++. A great example for this is LLVM and Clang code base. I hope this is also possible to do this in D too. Any way it would be better if D Language would better support alternative error handling system.
Jun 05 2014