www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D mention on developer.apple.com

reply Michel Fortin <michel.fortin michelf.ca> writes:
Maybe this will be of interest to someone. D was mentioned on the 
official Swift Blog today:


 Swift borrows a clever feature from the D language: these identifiers 
 expand to the location of the caller when evaluated in a default 
 argument list.


-- Building assert() in Swift, Part 2: __FILE__ and __LINE__
<https://developer.apple.com/swift/blog/?id=15>

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Sep 25 2014
next sibling parent "j_lacaba12 yahoo.com" <jlacaba12 yahoo.com> writes:
On Friday, 26 September 2014 at 01:31:06 UTC, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned on 
 the official Swift Blog today:


 Swift borrows a clever feature from the D language: these 
 identifiers expand to the location of the caller when 
 evaluated in a default argument list.


 -- Building assert() in Swift, Part 2: __FILE__ and __LINE__
 <https://developer.apple.com/swift/blog/?id=15>
Sep 25 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 26/09/14 03:31, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned on the
 official Swift Blog today:


 Swift borrows a clever feature from the D language: these identifiers
 expand to the location of the caller when evaluated in a default
 argument list.


 -- Building assert() in Swift, Part 2: __FILE__ and __LINE__
 <https://developer.apple.com/swift/blog/?id=15>


Cool, I didn't know that.

-- 
/Jacob Carlborg
Sep 25 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 26 September 2014 at 06:37:49 UTC, Jacob Carlborg 
wrote:

 On 26/09/14 03:31, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned on 
 the
 official Swift Blog today:


 Swift borrows a clever feature from the D language: these 
 identifiers
 expand to the location of the caller when evaluated in a 
 default
 argument list.


 -- Building assert() in Swift, Part 2: __FILE__ and __LINE__
 <https://developer.apple.com/swift/blog/?id=15>


 Cool, I didn't know that.


See, D is not all that bad :)
Sep 26 2014
next sibling parent reply "Daniel N" <ufo orbiting.us> writes:
On Friday, 26 September 2014 at 09:18:20 UTC, Chris wrote:

 On Friday, 26 September 2014 at 06:37:49 UTC, Jacob Carlborg 
 wrote:

 On 26/09/14 03:31, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned on 
 the
 official Swift Blog today:


 Swift borrows a clever feature from the D language: these 
 identifiers
 expand to the location of the caller when evaluated in a 
 default
 argument list.








Swift also kinda borrowed "lazy" as  autoclosure... but actually 
lazy is slightly more powerful.

"Those who do not understand D are condemned to reinvent it, 
poorly." ;)
Sep 26 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 26 September 2014 at 10:48:29 UTC, Daniel N wrote:

 On Friday, 26 September 2014 at 09:18:20 UTC, Chris wrote:

 On Friday, 26 September 2014 at 06:37:49 UTC, Jacob Carlborg 
 wrote:

 On 26/09/14 03:31, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned 
 on the
 official Swift Blog today:


 Swift borrows a clever feature from the D language: these 
 identifiers
 expand to the location of the caller when evaluated in a 
 default
 argument list.








 Swift also kinda borrowed "lazy" as  autoclosure... but 
 actually lazy is slightly more powerful.


I'm lazy, but not powerful :-)


 "Those who do not understand D are condemned to reinvent it, 
 poorly." ;)


But it will be a "killer feature" in any other language.
Sep 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 7:49 AM, Chris wrote:

 On Friday, 26 September 2014 at 10:48:29 UTC, Daniel N wrote:

 On Friday, 26 September 2014 at 09:18:20 UTC, Chris wrote:

 On Friday, 26 September 2014 at 06:37:49 UTC, Jacob Carlborg wrote:

 On 26/09/14 03:31, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned on the
 official Swift Blog today:


 Swift borrows a clever feature from the D language: these identifiers
 expand to the location of the caller when evaluated in a default
 argument list.








 Swift also kinda borrowed "lazy" as  autoclosure... but actually lazy is
 slightly more powerful.


 I'm lazy, but not powerful :-)


 "Those who do not understand D are condemned to reinvent it, poorly." ;)


 But it will be a "killer feature" in any other language.


Amusingly, the "Language Game Development Talk" video has a list of a dozen 
features wanted in a game programming language that are already in D. Including 
the speaker's great invention of D dynamic arrays!

Features of D are creeping into other languages right and left, but nobody
wants 
to say they came from D.
Sep 26 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 11:23 AM, Walter Bright wrote:

 Features of D are creeping into other languages right and left, but nobody
wants
 to say they came from D.


I see the Apple blog did mention D. A glorious exception!
Sep 26 2014
parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 9/26/14, 11:25 AM, Walter Bright wrote:

 I see the Apple blog did mention D. A glorious exception!


Which is odd because Swift doesn't support exception handling :)
Sep 26 2014
next sibling parent "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
On Friday, 26 September 2014 at 18:29:15 UTC, David Gileadi wrote:

 On 9/26/14, 11:25 AM, Walter Bright wrote:

 I see the Apple blog did mention D. A glorious exception!


 Which is odd because Swift doesn't support exception handling :)


:D
Sep 26 2014
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 26 September 2014 at 18:29:15 UTC, David Gileadi wrote:

 On 9/26/14, 11:25 AM, Walter Bright wrote:

 I see the Apple blog did mention D. A glorious exception!


 Which is odd because Swift doesn't support exception handling :)


 From what I got on release Swift is quite odd:
- regular integer operators check for overflow, but wait it also 
has other operators that do not.
- user-defined custom operators like =+= with _user-defined 
priority_
- type inference is "bidirectional by expression or statement" 
which is something that I don't really understand but can only 
fear
- many refinement for properties, convenience is a keyword
- and no exceptions, just because
Sep 27 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-09-27 11:05, ponce wrote:


 - and no exceptions, just because


The Objective-C frameworks by Apple basically never throw exceptions.

-- 
/Jacob Carlborg
Sep 27 2014
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-09-27 10:02:59 +0000, Jacob Carlborg <doob me.com> said:


 On 2014-09-27 11:05, ponce wrote:
 

 - and no exceptions, just because


 
 The Objective-C frameworks by Apple basically never throw exceptions.


There's that.

Also, remember Walter's fear of ARC in D that would be bloating the 
generated code by implicitly adding exception handlers all over the 
place? Well, Swift won't have to bother about that. I'm not claiming 
that is why there's no exception in Swift, but it's an interesting 
conjecture.

The Cocoa error handling pattern is rather ugly to use in Swift at the 
moment. I hypothesize they'll come up with something later on the error 
handling front.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Sep 27 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 10:48:27AM +0000, Daniel N via Digitalmars-d wrote:
[...]

 "Those who do not understand D are condemned to reinvent it, poorly." ;)


Stolen for my sigs file. :-)


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond
Sep 26 2014
prev sibling parent reply "AsmMan" <jckj33 gmail.com> writes:
On Friday, 26 September 2014 at 09:18:20 UTC, Chris wrote:

 On Friday, 26 September 2014 at 06:37:49 UTC, Jacob Carlborg 
 wrote:

 On 26/09/14 03:31, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned on 
 the
 official Swift Blog today:


 Swift borrows a clever feature from the D language: these 
 identifiers
 expand to the location of the caller when evaluated in a 
 default
 argument list.


 -- Building assert() in Swift, Part 2: __FILE__ and __LINE__
 <https://developer.apple.com/swift/blog/?id=15>


 Cool, I didn't know that.


 See, D is not all that bad :)


Who thinks so?
Sep 26 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 26 September 2014 at 15:01:20 UTC, AsmMan wrote:

 On Friday, 26 September 2014 at 09:18:20 UTC, Chris wrote:

 On Friday, 26 September 2014 at 06:37:49 UTC, Jacob Carlborg 
 wrote:

 On 26/09/14 03:31, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned 
 on the
 official Swift Blog today:


 Swift borrows a clever feature from the D language: these 
 identifiers
 expand to the location of the caller when evaluated in a 
 default
 argument list.


 -- Building assert() in Swift, Part 2: __FILE__ and __LINE__
 <https://developer.apple.com/swift/blog/?id=15>


 Cool, I didn't know that.


 See, D is not all that bad :)


 Who thinks so?


The Whine Club :-))) Just kidding. The latest threads were just a 
bit heated up at times.
Sep 26 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 03:25:10PM +0000, Chris via Digitalmars-d wrote:

 On Friday, 26 September 2014 at 15:01:20 UTC, AsmMan wrote:

On Friday, 26 September 2014 at 09:18:20 UTC, Chris wrote:




[...]

See, D is not all that bad :)


Who thinks so?


 
 The Whine Club :-))) Just kidding. The latest threads were just a bit
 heated up at times.


Yeah, but the way I see it is, people get heated up over it because D is
cool enough to matter to them. If D were really that horrible, people
would just leave and not bother to get involved in the first place. It's
not as though we have the kind of marketshare C++ has, where in some
places it's basically shoved down your throat, like it or not.


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Sep 26 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 26 Sep 2014 09:18:50 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:


 Yeah, but the way I see it is, people get heated up over it because D
 is cool enough to matter to them. If D were really that horrible,
 people would just leave and not bother to get involved in the first
 place.


yep, there is no sense to talk about "better D" if D is bad in the
first place. ;-)
Sep 26 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 26 September 2014 at 01:31:06 UTC, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned on 
 the official Swift Blog today:


 Swift borrows a clever feature from the D language: these 
 identifiers expand to the location of the caller when 
 evaluated in a default argument list.


 -- Building assert() in Swift, Part 2: __FILE__ and __LINE__
 <https://developer.apple.com/swift/blog/?id=15>


Funny, this is one feature I would never recognize as a distinct 
feature at all :)
Sep 26 2014
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/26/14 6:48 AM, Dicebot wrote:

 On Friday, 26 September 2014 at 01:31:06 UTC, Michel Fortin wrote:

 Maybe this will be of interest to someone. D was mentioned on the
 official Swift Blog today:


 Swift borrows a clever feature from the D language: these identifiers
 expand to the location of the caller when evaluated in a default
 argument list.


 -- Building assert() in Swift, Part 2: __FILE__ and __LINE__
 <https://developer.apple.com/swift/blog/?id=15>


 Funny, this is one feature I would never recognize as a distinct feature
 at all :)


It's really funny how the simplest easiest things, if they solve a 
common nuisance problem, are treated like amazing inventions. We have a 
similar situation for one product in our company. We make walk-in cooler 
controls. After installing our controls, we started getting calls that 
the coolers were iced up. The problem usually turned out to be that a 
person who was loading the cooler shut off the evaporator fans (the fans 
that blow air across the refrigerant coils), and forgot to turn them 
back on. This results in refrigerant running through the coils, but 
since air is a great insulator, it did not consume any heat from the 
cooler. Condensation builds up on the coils and turns into ice, which is 
an even better insulator :)

Now, the people doing this had been doing this long before we installed 
our controls. If you want to know why, just look up wind chill :)

The solution we came up with was simple and stupid: add a button that 
shut off the fans for 10 minutes.

That one feature is raved about time and again by all our customers. 
It's the dumbest thing, but it makes things so much more pleasant that 
people now complain if the controller needs service because they "can't 
live without the shutdown button!"

And to think we put it in to save service calls :)

-Steve
Sep 26 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/26/2014 11:34 AM, Steven Schveighoffer wrote:

 It's really funny how the simplest easiest things, if they solve a common
 nuisance problem, are treated like amazing inventions. We have a similar
 situation for one product in our company. We make walk-in cooler controls.
After
 installing our controls, we started getting calls that the coolers were iced
up.
 The problem usually turned out to be that a person who was loading the cooler
 shut off the evaporator fans (the fans that blow air across the refrigerant
 coils), and forgot to turn them back on. This results in refrigerant running
 through the coils, but since air is a great insulator, it did not consume any
 heat from the cooler. Condensation builds up on the coils and turns into ice,
 which is an even better insulator :)

 Now, the people doing this had been doing this long before we installed our
 controls. If you want to know why, just look up wind chill :)

 The solution we came up with was simple and stupid: add a button that shut off
 the fans for 10 minutes.

 That one feature is raved about time and again by all our customers. It's the
 dumbest thing, but it makes things so much more pleasant that people now
 complain if the controller needs service because they "can't live without the
 shutdown button!"

 And to think we put it in to save service calls :)


It's really fun when us engineers can make improvements like that!
Sep 27 2014