www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DConf Day 1 Panel with Walter Bright and Andrei Alexandrescu

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.reddit.com/r/programming/comments/298vtt/dconf_2014_panel_with_walter_bright_and_andrei/

https://twitter.com/D_Programming/status/482546357690187776

https://news.ycombinator.com/newest

https://www.facebook.com/dlang.org/posts/874091959271153


Andrei
Jun 27 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
http://youtu.be/TNvUIWFy02I
Jun 27 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/27/2014 12:53 PM, Dicebot wrote:
 http://youtu.be/TNvUIWFy02I
Ack, need to work on my posture :-(
Jun 27 2014
parent "Brian Rogoff" <brogoff gmail.com> writes:
On Friday, 27 June 2014 at 20:39:10 UTC, Walter Bright wrote:
 On 6/27/2014 12:53 PM, Dicebot wrote:
 http://youtu.be/TNvUIWFy02I
Ack, need to work on my posture :-(
I just got a chance to watch this, and one thing that I found more unsettling than your posture was your assertion that destructors and finalizers are "the same thing", in contrast to Hans-J. Boehm, who asserts that C++ destructors and Java finalizers "are completely different facilities". I assume that you've read Boehm's report http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html and if so I'd be interested in why you think he is mistaken, since both of your statements can't be correct.
Jul 02 2014
prev sibling next sibling parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
I have two questions that I've come upon lately:

1) How was it decided that there should be implicit conversion 
between signed and unsigned integers in arithmetic operations, 
and why prefer unsigned numbers?
E.g. Signed / Unsigned = Unsigned
Is this simply compatibility with C or is there something greater 
behind this decision.

2) With regard to reducing template instantiations:
I've been using a technique similar to the one mentioned in the 
video: separating functions out of templates to reduce bloat.
My question is: does a template such as:
T foo(T)(T x)
if (isIntegral!T) { return x; }

Get instantiated multiple times for const, immutable, etc. 
qualifiers on the input?
Jun 27 2014
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 27 June 2014 at 23:30:39 UTC, safety0ff wrote:
 2) With regard to reducing template instantiations:
 I've been using a technique similar to the one mentioned in the 
 video: separating functions out of templates to reduce bloat.
 My question is: does a template such as:
 T foo(T)(T x)
 if (isIntegral!T) { return x; }

 Get instantiated multiple times for const, immutable, etc. 
 qualifiers on the input?
Yes, but bear in mind that those qualifiers are often stripped with IFTI, e.g.: int a; const int b; immutable int c; foo(a); foo(b); foo(c); These all call foo!int
Jun 27 2014
parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
On Saturday, 28 June 2014 at 02:02:28 UTC, Peter Alexander wrote:
 On Friday, 27 June 2014 at 23:30:39 UTC, safety0ff wrote:
 2) With regard to reducing template instantiations:
 I've been using a technique similar to the one mentioned in 
 the video: separating functions out of templates to reduce 
 bloat.
 My question is: does a template such as:
 T foo(T)(T x)
 if (isIntegral!T) { return x; }

 Get instantiated multiple times for const, immutable, etc. 
 qualifiers on the input?
Yes, but bear in mind that those qualifiers are often stripped with IFTI, e.g.: int a; const int b; immutable int c; foo(a); foo(b); foo(c); These all call foo!int
Awesome, thanks!
Jun 27 2014
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 28 June 2014 at 02:46:25 UTC, safety0ff wrote:
 On Saturday, 28 June 2014 at 02:02:28 UTC, Peter Alexander
 int a;
 const int b;
 immutable int c;
 foo(a);
 foo(b);
 foo(c);

 These all call foo!int
Awesome, thanks!
... I just tried this and I'm wrong. The qualifier isn't stripped. Gah! Three different versions! I could have sworn D did this for primitive types. This makes me sad :-(
Jun 27 2014
next sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Saturday, 28 June 2014 at 03:33:37 UTC, Peter Alexander wrote:
 ... I just tried this and I'm wrong. The qualifier isn't 
 stripped. Gah! Three different versions!

 I could have sworn D did this for primitive types. This makes 
 me sad :-(
I guess you can make all kinds of code that depends on the qualifier. I tried using ld.gold to play with icf (identical code folding,) but I did not manage to get a working binary out of gold (regardless of icf.)
Jun 27 2014
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 28.06.2014 05:33, schrieb Peter Alexander:
 On Saturday, 28 June 2014 at 02:46:25 UTC, safety0ff wrote:
 On Saturday, 28 June 2014 at 02:02:28 UTC, Peter Alexander
 int a;
 const int b;
 immutable int c;
 foo(a);
 foo(b);
 foo(c);

 These all call foo!int
Awesome, thanks!
... I just tried this and I'm wrong. The qualifier isn't stripped. Gah! Three different versions! I could have sworn D did this for primitive types. This makes me sad :-(
I *think* it does this if you define foo as "foo(T)(const(T) arg)", though.
Jun 28 2014
parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Saturday, 28 June 2014 at 16:51:56 UTC, Sönke Ludwig wrote:
 Am 28.06.2014 05:33, schrieb Peter Alexander:
 On Saturday, 28 June 2014 at 02:46:25 UTC, safety0ff wrote:
 On Saturday, 28 June 2014 at 02:02:28 UTC, Peter Alexander
 int a;
 const int b;
 immutable int c;
 foo(a);
 foo(b);
 foo(c);

 These all call foo!int
Awesome, thanks!
... I just tried this and I'm wrong. The qualifier isn't stripped. Gah! Three different versions! I could have sworn D did this for primitive types. This makes me sad :-(
I *think* it does this if you define foo as "foo(T)(const(T) arg)", though.
Thanks, that works. std.math doesn't do this for its templated functions, should it? Is there an easy way to shared-strip primitive types? Perhaps passing non-ref/non-pointer primitive data to const(T) should implicitly strip shared. Reading of the shared data occurs at the call site. Are there any use cases where passing on the shared-ness of a primitive type to non-ref const(T) is useful?
Jun 28 2014
prev sibling parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 27 June 2014 at 15:31:17 UTC, Andrei Alexandrescu 
wrote:
 http://www.reddit.com/r/programming/comments/298vtt/dconf_2014_panel_with_walter_bright_and_andrei/

 https://twitter.com/D_Programming/status/482546357690187776

 https://news.ycombinator.com/newest

 https://www.facebook.com/dlang.org/posts/874091959271153


 Andrei
Tuple destructuring syntax, straight from the horse's mouth =) However, you said that you want destructuring for std.typecons.Tuple. Does this extend to built-in tuples? Looking at Kenji's DIP[1], it seems the proposed syntax is for built-in tuples.
Jun 28 2014
parent "Meta" <jared771 gmail.com> writes:
On Sunday, 29 June 2014 at 02:07:48 UTC, Meta wrote:
 On Friday, 27 June 2014 at 15:31:17 UTC, Andrei Alexandrescu 
 wrote:
 http://www.reddit.com/r/programming/comments/298vtt/dconf_2014_panel_with_walter_bright_and_andrei/

 https://twitter.com/D_Programming/status/482546357690187776

 https://news.ycombinator.com/newest

 https://www.facebook.com/dlang.org/posts/874091959271153


 Andrei
Tuple destructuring syntax, straight from the horse's mouth =) However, you said that you want destructuring for std.typecons.Tuple. Does this extend to built-in tuples? Looking at Kenji's DIP[1], it seems the proposed syntax is for built-in tuples.
Whoops, link to the DIP: http://wiki.dlang.org/DIP32
Jun 28 2014