www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Three Unlikely Successful Features of D

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I plan to give a talk at Lang.NEXT 
(http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the 
subject above. There are a few features of D that turned out to be 
successful, in spite of them being seemingly unimportant or diverging 
from related consecrated approaches.

What are your faves? I have a few in mind, but wouldn't want to 
influence answers.


Thanks,

Andrei
Mar 20 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 20-03-2012 20:02, Andrei Alexandrescu wrote:
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or diverging
 from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.


 Thanks,

 Andrei

In no particular order: Lazy values, guaranteed initialization, scope guards, perhaps array slices, alias this / single inheritance, unittest blocks. -- - Alex
Mar 20 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 20.03.2012 23:02, Andrei Alexandrescu wrote:
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or diverging
 from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

To throw in a few: Scope guards, opDispatch, alias and _string_ template parameters. -- Dmitry Olshansky
Mar 20 2012
next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Tuesday, 20 March 2012 at 19:50:25 UTC, Dmitry Olshansky wrote:

 To throw in a few:
 Scope guards, opDispatch, alias and _string_ template 
 parameters.

I like this list. And add, the template shorthand to!(int)() -> to!int() and q{} strings (though I need to remember them more often.
Mar 20 2012
prev sibling parent bcs <bcs example.com> writes:
On 03/20/2012 12:50 PM, Dmitry Olshansky wrote:
 On 20.03.2012 23:02, Andrei Alexandrescu wrote:
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or diverging
 from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

To throw in a few: Scope guards, opDispatch, alias and _string_ template parameters.

that and d2 operator overloading.
Mar 20 2012
prev sibling next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
--e89a8ffbabadde752904bbb1db92
Content-Type: text/plain; charset=ISO-8859-1

I really like the $ opperator on slices. It's something small and looks
rather unneeded. When I was dealing with java I never even wished it was
there but when I came to d and did some array manipulation I was really
glad we had that $ sign. I regularly use it and I don't seem to be the only
one feeling that way.

Maarten

--e89a8ffbabadde752904bbb1db92
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I really like the $ opperator on slices. It&#39;s something small and looks=
 rather unneeded. When I was dealing with java I never even wished it was t=
here but when I came to d and did some array manipulation I was really glad=
 we had that $ sign. I regularly use it and I don&#39;t seem to be the only=
 one feeling that way.<div>
<br></div><div>Maarten</div>

--e89a8ffbabadde752904bbb1db92--
Mar 20 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 20, 2012 at 02:02:15PM -0500, Andrei Alexandrescu wrote:
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or
 diverging from related consecrated approaches.
 
 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

By far: CTFE. Unittest blocks, extended concept of purity, template syntax (as opposed to C++'s ugly mess), all types have a default value (.init - makes it so painless to write generic code!), scope guards. T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Mar 20 2012
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
On 20.03.2012 20:02, Andrei Alexandrescu wrote:
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or diverging
 from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.


 Thanks,

 Andrei

There's one huge one. Strings as built-in types, including concatenation and slicing. This meant that they could be constant-folded. Together with 'static if', this was the basis of metaprogramming in D. Pretty much all the rest was a natural consequence of that foundation. It was *completely* unexpected. When, as a D newbie, I posted some of my initial exploration of the language, Walter wrote "I had no idea this was even possible." Probably not what you have in mind, though -- it *was* expected to be a success, just not to anything like this extent. * pragma(msg) is something that's been used 100X as often as anticipated. * Builtin properties of types, eg int.max. Doesn't sound like much of an improvement over a header file of constants, but it's had a huge impact. It really encourages you to write correct code, (I especially notice it for floating point, but I bet if you grep for "int.max" in D code, you'll get far more hits than for "MAXINT" in C code).
Mar 20 2012
parent reply Don <nospam nospam.com> writes:
On 20.03.2012 21:33, Don wrote:
 On 20.03.2012 20:02, Andrei Alexandrescu wrote:
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or diverging
 from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.


 Thanks,

 Andrei

There's one huge one. Strings as built-in types, including concatenation and slicing. This meant that they could be constant-folded. Together with 'static if', this was the basis of metaprogramming in D. Pretty much all the rest was a natural consequence of that foundation. It was *completely* unexpected. When, as a D newbie, I posted some of my initial exploration of the language, Walter wrote "I had no idea this was even possible." Probably not what you have in mind, though -- it *was* expected to be a success, just not to anything like this extent. * pragma(msg) is something that's been used 100X as often as anticipated.

Note that because it was so successful, it was incorporated into static assert.
 * Builtin properties of types, eg int.max. Doesn't sound like much of an
 improvement over a header file of constants, but it's had a huge impact.
 It really encourages you to write correct code, (I especially notice it
 for floating point, but I bet if you grep for "int.max" in D code,
 you'll get far more hits than for "MAXINT" in C code).

And is(typeof()), even though the syntax is really horrible. Brilliant concept.
Mar 20 2012
parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Tue, 20 Mar 2012, Don wrote:

 On 20.03.2012 21:33, Don wrote:
 * pragma(msg) is something that's been used 100X as often as anticipated.

Note that because it was so successful, it was incorporated into static assert.

I wrote the original msg part of assert and static assert. It wasn't because of pragma(msg), it was because I wanted a message with my asserts. :) Later, Brad
Mar 20 2012
prev sibling next sibling parent "dsimcha" <dsimcha yahoo.com> writes:
1.  Scope guards.  The need to execute some code at the end of a
scope is pervasive and has led to about a zillion workarounds
from gotos in C to RAII in C++ to try/finally in Java and C# to
with statements in Python.  D is the only language I know of that
lets the programmer specify such a simple and common intention
directly.

2.  CTFE.  There's a certain elegance to having most of the
language available at compile time and it seems like there's no
shortage of creative uses for this.

3.  Static if.  This is the most important feature for converting
template metaprogramming from an esoteric form of sorcery to a
practical, readable tool for the masses.  Most of the compile time
introspection D provides would be almost unusable without it.
Mar 20 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 20, 2012 at 01:31:08PM -0700, H. S. Teoh wrote:
 On Tue, Mar 20, 2012 at 02:02:15PM -0500, Andrei Alexandrescu wrote:
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or
 diverging from related consecrated approaches.
 
 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

By far: CTFE. Unittest blocks, extended concept of purity, template syntax (as opposed to C++'s ugly mess), all types have a default value (.init - makes it so painless to write generic code!), scope guards.

Oh, and I forgot static if. It's a major feature in making compile-time stuff work like a charm. T -- Life is too short to run proprietary software. -- Bdale Garbee
Mar 20 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/20/2012 12:02 PM, Andrei Alexandrescu wrote:
 What are your faves? I have a few in mind, but wouldn't want to influence
answers.

Although array slices have been in D nearly since the beginning, I had little idea they would become so darn useful and foundational. They originated from an idea by Jan Knepper. The unexpected utility of them explains why they haven't appeared in other languages (yet).
Mar 20 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/20/12 4:43 PM, Walter Bright wrote:
 On 3/20/2012 12:02 PM, Andrei Alexandrescu wrote:
 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

Although array slices have been in D nearly since the beginning, I had little idea they would become so darn useful and foundational. They originated from an idea by Jan Knepper. The unexpected utility of them explains why they haven't appeared in other languages (yet).

Go has slices. (Unlike D slices, they include capacity.) Andrei
Mar 20 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/20/2012 2:51 PM, Andrei Alexandrescu wrote:
 On 3/20/12 4:43 PM, Walter Bright wrote:
 On 3/20/2012 12:02 PM, Andrei Alexandrescu wrote:
 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

Although array slices have been in D nearly since the beginning, I had little idea they would become so darn useful and foundational. They originated from an idea by Jan Knepper. The unexpected utility of them explains why they haven't appeared in other languages (yet).

Go has slices. (Unlike D slices, they include capacity.)

Can you, in Go: 1. slice a static string? 2. slice any arbitrary data?
Mar 20 2012
parent bcs <bcs example.com> writes:
On 03/20/2012 04:10 PM, Walter Bright wrote:
 On 3/20/2012 2:51 PM, Andrei Alexandrescu wrote:
 On 3/20/12 4:43 PM, Walter Bright wrote:
 On 3/20/2012 12:02 PM, Andrei Alexandrescu wrote:
 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

Although array slices have been in D nearly since the beginning, I had little idea they would become so darn useful and foundational. They originated from an idea by Jan Knepper. The unexpected utility of them explains why they haven't appeared in other languages (yet).

Go has slices. (Unlike D slices, they include capacity.)

Can you, in Go: 1. slice a static string? 2. slice any arbitrary data?

3. have arbitrary overlapping slices? OTOH slices in D do have a capacity in some regards in that the GC can allow in place extend.
Mar 20 2012
prev sibling next sibling parent Jan Knepper <jan smartsoft.us> writes:
On 03/20/2012 17:43, Walter Bright wrote:
 On 3/20/2012 12:02 PM, Andrei Alexandrescu wrote:
 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

Although array slices have been in D nearly since the beginning, I had little idea they would become so darn useful and foundational. They originated from an idea by Jan Knepper. The unexpected utility of them explains why they haven't appeared in other languages (yet).

Oh... I remember those early D-Days...
Mar 21 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 20 March 2012 at 21:43:25 UTC, Walter Bright wrote:
 On 3/20/2012 12:02 PM, Andrei Alexandrescu wrote:
 What are your faves? I have a few in mind, but wouldn't want 
 to influence answers.

Although array slices have been in D nearly since the beginning, I had little idea they would become so darn useful and foundational. They originated from an idea by Jan Knepper. The unexpected utility of them explains why they haven't appeared in other languages (yet).

As to me, slices are the most important feature of D, and they were the major improvement from the start, aimed to fix the buffer overflow vulnerabilities - the plague of low level languages - at the lowest cost. What can do more than that? I thought they were born to be epic: safety, minimalism a efficiency combined.
Mar 21 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Andrei Alexandrescu wrote:
 What are your faves?

opDispatch was expectantly successful for me. I haven't seen it often used in examples or others peoples code, but it allows for some really awesome stuff. For instance, who says D doesn't have multiple inheritance? struct A { void a() { writeln("a"); } } struct B { void b() { writeln("b"); } } struct C { private A _a; private B _b; void opDispatch(string s)() { static if (__traits(hasMember, A, s)) mixin("_a."~s~"();"); else if (__traits(hasMember, B, s)) mixin("_b."~s~"();"); else static assert("Method not found."); } } void main() { auto c = C(); c.a(); c.b(); } and similarly, "alias x this" is useful for pseudo hierarchy. The only down-side to doing this is that Mono-D doesn't currently parse the syntax.
Mar 20 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 20/03/2012 20:02, Andrei Alexandrescu a écrit :
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or diverging
 from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.


 Thanks,

 Andrei

To me it is pragma(msg, blabla) and slices.
Mar 20 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
deadalnix wrote:
 Le 20/03/2012 20:02, Andrei Alexandrescu a écrit :
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or diverging
 from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.


 Thanks,

 Andrei

To me it is pragma(msg, blabla) and slices.

Yes, pragma(msg, ...) is very handy when debugging templates and generic code.
Mar 20 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/20/12, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

Here's one: C compatibility. Maybe it wasn't "unlikely" to be successful but most new languages don't seem to care about C compatibility all that much. It's been a boon for D though.
Mar 20 2012
prev sibling next sibling parent David <d dav1d.de> writes:
I really love CTFE, even though it's sometimes pretty slow, maybe 
because I am axaggerating it …

One more thing are these slices, they really impressed me when working 
with pointers, float* v; v[x..y] = foo; ! awesome, no more memcpy

And of yourse opDispatch, I haven't used it a lot yet, just in gl3n for 
vector swizzling, I've seen glms swizzling ... I thought I can never do 
this in D, I made it in nearly no time and 10 lines of code!
Mar 20 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/20/12, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 Here's one: C compatibility.

Now a real one: auto type inference. Could you possibly imagine what the type name should be on the left-hand side? ? x = retro(stride(chain([1, 2], [3, 4]), 2)); Who knows. auto is great for these higher-level types.
Mar 20 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
- Type inference
- alias
- foreach
- Everything about arrays/slices
- Built-in associative arrays that support nearly any type as a key
- Reference semantics for classes
- All the niceities of ctors compared with C++'s ctors
- Backtick strings
- Scope guards (And even finally: I head somewhere C++ doesn't even have 
finally: Is that true?!?)
- GC
- Name any of D's metaprogramming features

Many of those can seem like simple things, but I'd *hate* to have to get by 
without them. Heck, most of them I now take for granted.

Alias in particular is a much bigger deal than it seems since it's seemingly 
trivial but can be *incredibly* helpful with templates *and* with importing.

Actually, looking at this list, I'm now starting to get a little worried 
about an upcoming C++ project... No doubt I'll be trying to reinvent a lot 
of D in it. Probably in ugly hackish ways.
Mar 20 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/20/2012 3:58 PM, Nick Sabalausky wrote:
 Alias in particular is a much bigger deal than it seems since it's seemingly
 trivial but can be *incredibly* helpful with templates *and* with importing.

I'd have to agree with this. I find it amazing that other languages entirely miss the boat on this. C++ has a very crippled version of it in "template template parameters".
Mar 20 2012
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jkb2v6$kq4$2 digitalmars.com...
 On 3/20/2012 3:58 PM, Nick Sabalausky wrote:
 Alias in particular is a much bigger deal than it seems since it's 
 seemingly
 trivial but can be *incredibly* helpful with templates *and* with 
 importing.

I'd have to agree with this. I find it amazing that other languages entirely miss the boat on this. C++ has a very crippled version of it in "template template parameters".

I particulary love how D's alias is used to disambiguate symbol conflicts. Brilliant approach. I know I wouldn't have thought of it.
Mar 20 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.933.1332286692.4860.digitalmars-d puremagic.com...
 On Tue, Mar 20, 2012 at 06:58:31PM -0400, Nick Sabalausky wrote:
 - Type inference

Yeah I forgot about this one. Being able to write: auto veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); is a big boon over C++ or Java's stuttering verbosity: VeryLongNamedClass veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); Plus, it's immensely useful when dealing with Range templates... can you imagine the horrifically long typenames you'd have to type you have to explicitly specify the type of a long chain of functional expressions involving 15+ std.algorithm and std.range templates?
 - alias

This, together with static ifs and templates, make for awesome tricks involving templates that would've been an utter bear to pull off in C++. template innerKeyType(T) { static if (is(T U : U[K], K)) alias innerKeyType!K innerKeyType; else alias T innerKeyType; } innerKeyType!(int[string[char[byte]]]) innerKey;

Yea, C++'s STL *needs* type inference and alias. At least the new spec has "auto". Don't know about other stuff though.
 [...]
 - Built-in associative arrays that support nearly any type as a key

This is actually quite buggy right now... but that's merely an implementation issue. :-)

Heck, I just love that I can use a string, or an int, or make my own struct work as a key, etc. Actually, over just the last 24 hours I've been making a lot of use of AAs with int keys. (AA's make it *so* much easier to avoid poor time complexity in a lot of things.) Many langauges (like Haxe, for example) will have hashtables, and may even have them templated (or otherwise generic) on *value*, but the keys will be string-only. Which is still very useful, but it also misses out on many other use-cases.
 My new AA implementation, for example,
 already correctly supports AA's with AA keys, which can be arbitrarily
 nested. So you could have something like int[string[char[byte]]], and it
 does lookups correctly based on the contents of the AA's you pass in as
 key.

Crazy stuff :) Actually I've been meaning to ask what the main benefits of your new AA implementation are. I know there's the benefit of just simply having it be implemented in the library. And you mention using AA's as AA keys here. Are there any other, umm, "key" points?
 - All the niceities of ctors compared with C++'s ctors

C++ ctors are a royal pain in the neck. I remember in the early days of C++ when you can still call the base class ctor in the body of the derived class ctor... nowadays you have to contort ctor code into a horrible ugly mess just to get your ctor to do things right. Plus, the C++ standard requires fields to be initialized in declaration order, which is needlessly restrictive and basically makes ctors even more of a pain. I ended up using just stub ctors for a lot of my code, and doing the actual initialization after the object is constructed. Which is very bad OO style, I agree, but the pain of working with C++ ctors just pushes me in the wrong direction, y'know?

Yea, that's what I've been planning on doing with the C++ stuff I have coming up. Don't even want to bother with C++'s ctor limitations. Just make an init() member and be done with it. Actually, that seems to be turning into more and more of a common C++ idiom though, from what (little) I've seen.
 - Scope guards (And even finally: I head somewhere C++ doesn't even have
 finally: Is that true?!?)

Yes, it's true. I don't know about C++11, but certainly the previous standard has no finally clause, leading to horribly unmaintainable and ugly code like: Resource r = acquireResource(); try { doSomethingDangerous(); } catch(...) { r.release(); } r.release();

Haxe also lacks finally! Which I always found rediculous. So yea, I'm intimately familiar with that idiom. I've used it myself far more than I would like. And even *that* still doesn't work if you don't catch *every* exception (and then rethrow the ones you don't care about? Ick!). I've seen C++ programmers swear off exceptions because of this, and I can't blame them at all. Exception systems *need* a finally.
 (Yes, yes, I know, RAII and all that... which leads to inventing
 ridiculous classes which make no sense in terms of OO, just to wrap
 resource handles.)

Yea, if I wanted to write Java-style code, I'd just use Java (and at least not have to deal with header files).
 - GC

For all the warts the current GC has, the fact that D has a GC at all makes things like array slicing possible, and *fast*, which leads to all the other niceties of slicing.

I used to do indie game dev in C/C++ and I feel downright spoiled now with tossing in a "new" whenever appropriate and not have to worry about cleanup (and even that wouldn't be *too* bad...in certain cases...if there were at least scope guards).
 - Name any of D's metaprogramming features

 Alias in particular is a much bigger deal than it seems since it's
 seemingly trivial but can be *incredibly* helpful with templates *and*
 with importing.

Definitely. Using alias and static if in a recursive template is one of the hallmarks of the awesomeness of D templates.

I'd say one of the hallmarks of D's metaprogramming is the enormous *decrease* in the need for recursive templates in the first place ;) With C++'s templates, it would appear that you have to use recursion and helper templates for damn near anything.
 Actually, looking at this list, I'm now starting to get a little worried
 about an upcoming C++ project... No doubt I'll be trying to reinvent a 
 lot
 of D in it. Probably in ugly hackish ways.

#include "dmd.h" ;-)

Heh, yea. :)
 -- 
 Don't modify spaghetti code unless you can eat the consequences.

Hah! :)
Mar 20 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jkbcoh$15k3$1 digitalmars.com...
 And even *that* still doesn't work if you don't catch *every* exception 
 (and then rethrow the ones you don't care about? Ick!).

And AIUI, even *that* doesn't work in C++ because, IIRC, the class hierarchy doesn't have *any* common root. So what, are you going to have a catch block for *every* class type in your program? Heck, even *that* might be feasable in D thanks to the compile-time reflection and quality metaprogramming, but with C++, you're SOL.
Mar 20 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-21 20:49, Sean Kelly wrote:

 Druntime actually did use MurmurHash for a while and then dropped it because
the site had no copyright license for the code (a mistake that has since been
rectified).  I'd consider switching back, though I don't really like that
MurmurHash has a number of separate implementations targeted at different
platforms, each having different performance characteristics.  It's 4x faster
than SuperFastHash on x86 but 10x slower than SuperFastHash on SPARC, for
example.

Would it be possible to use different algorithms on different platforms? -- /Jacob Carlborg
Mar 21 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/20/2012 4:39 PM, H. S. Teoh wrote:
 On Tue, Mar 20, 2012 at 06:58:31PM -0400, Nick Sabalausky wrote:
 - Type inference

Yeah I forgot about this one. Being able to write: auto veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); is a big boon over C++ or Java's stuttering verbosity: VeryLongNamedClass veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); Plus, it's immensely useful when dealing with Range templates... can you imagine the horrifically long typenames you'd have to type you have to explicitly specify the type of a long chain of functional expressions involving 15+ std.algorithm and std.range templates?

Andrei discovered an amazing use of auto. It enables you to create variables with voldemort types "that may not be named". For example: auto foo() { struct S { ... } S s; return s; } auto x = foo(); And now x is an instance of a voldemort type! It's completely encapsulated.
Mar 20 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/20/12 9:47 PM, Walter Bright wrote:
 auto foo()
 {
 struct S { ... }
 S s;
 return s;
 }

 auto x = foo();

 And now x is an instance of a voldemort type! It's completely encapsulated.

LOL. Heck, I'd include "Voldemort types" just because it sounds so cool. Andrei
Mar 20 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/20/2012 8:00 PM, Andrei Alexandrescu wrote:
 On 3/20/12 9:47 PM, Walter Bright wrote:
 And now x is an instance of a voldemort type! It's completely encapsulated.

LOL. Heck, I'd include "Voldemort types" just because it sounds so cool.

Yeah, I'm going to title my next blog entry that!
Mar 20 2012
prev sibling parent reply Don Clugston <dac nospam.com> writes:
On 21/03/12 03:47, Walter Bright wrote:
 On 3/20/2012 4:39 PM, H. S. Teoh wrote:
 On Tue, Mar 20, 2012 at 06:58:31PM -0400, Nick Sabalausky wrote:
 - Type inference

Yeah I forgot about this one. Being able to write: auto veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); is a big boon over C++ or Java's stuttering verbosity: VeryLongNamedClass veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); Plus, it's immensely useful when dealing with Range templates... can you imagine the horrifically long typenames you'd have to type you have to explicitly specify the type of a long chain of functional expressions involving 15+ std.algorithm and std.range templates?

Andrei discovered an amazing use of auto. It enables you to create variables with voldemort types "that may not be named". For example: auto foo() { struct S { ... } S s; return s; } auto x = foo(); And now x is an instance of a voldemort type! It's completely encapsulated.

That idiom is already built into the language. Anonymous nested classes don't have a name at all. auto x = new class { ... }
Mar 21 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/21/2012 8:21 AM, Don Clugston wrote:
 On 21/03/12 03:47, Walter Bright wrote:
 And now x is an instance of a voldemort type! It's completely encapsulated.

That idiom is already built into the language. Anonymous nested classes don't have a name at all. auto x = new class { ... }

True, but it's the ability to return them from a function that's new & cool! (Yes, I know you can return x as type "Object".)
Mar 21 2012
parent reply Don <nospam nospam.com> writes:
On 21.03.2012 18:14, Walter Bright wrote:
 On 3/21/2012 8:21 AM, Don Clugston wrote:
 On 21/03/12 03:47, Walter Bright wrote:
 And now x is an instance of a voldemort type! It's completely
 encapsulated.

That idiom is already built into the language. Anonymous nested classes don't have a name at all. auto x = new class { ... }

True, but it's the ability to return them from a function that's new & cool! (Yes, I know you can return x as type "Object".)

BTW what is 'nested' about anonymous nested classes? They seem to work anywhere! Can we just drop that from the name?
Mar 21 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/21/2012 09:00 PM, Don wrote:
 BTW what is 'nested' about anonymous nested classes? They seem to work
 anywhere! Can we just drop that from the name?

Seems reasonable. BTW: They don't work in a typeof expression: http://d.puremagic.com/issues/show_bug.cgi?id=7104
Mar 21 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/21/12, Walter Bright <newshound2 digitalmars.com> wrote:
 Andrei discovered an amazing use of auto.

It's funny how the book explicitly stated that this doesn't work (page 263): "Nested struct objects cannot be returned from functions because the caller doesn't have access to their type". I posted about this back in 2011: http://www.digitalmars.com/d/archives/digitalmars/D/Has_the_ban_on_returning_function_nested_structs_been_lifted_132233.html It might have been a relic from earlier TDPL writing when this feature didn't exist. :)
Mar 20 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 20, 2012 at 09:59:27PM -0400, Nick Sabalausky wrote:
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.933.1332286692.4860.digitalmars-d puremagic.com...
 On Tue, Mar 20, 2012 at 06:58:31PM -0400, Nick Sabalausky wrote:


 - Built-in associative arrays that support nearly any type as a key

This is actually quite buggy right now... but that's merely an implementation issue. :-)

Heck, I just love that I can use a string, or an int, or make my own struct work as a key, etc. Actually, over just the last 24 hours I've been making a lot of use of AAs with int keys. (AA's make it *so* much easier to avoid poor time complexity in a lot of things.)

Yeah, AA's with int keys are like arrays enhanced with O(1) insertion/removal and sparse storage (if you have very large indices, e.g.). :-) You can even have (pseudo) linear access if you iterate keys from 0 to $.
 Many langauges (like Haxe, for example) will have hashtables, and may
 even have them templated (or otherwise generic) on *value*, but the
 keys will be string-only. Which is still very useful, but it also
 misses out on many other use-cases.

Yep.
 My new AA implementation, for example, already correctly supports
 AA's with AA keys, which can be arbitrarily nested. So you could
 have something like int[string[char[byte]]], and it does lookups
 correctly based on the contents of the AA's you pass in as key.

Crazy stuff :) Actually I've been meaning to ask what the main benefits of your new AA implementation are. I know there's the benefit of just simply having it be implemented in the library. And you mention using AA's as AA keys here. Are there any other, umm, "key" points?

Haha, I love that pun. I would say the main benefit is having it implemented in the library, because that allows the implementation have direct access to key/value types. I didn't implement any clever new hashing algorithm at all, I just mainly followed the implementation in aaA.d. But having direct access to key/value types is a *huge* win. For example, it lets you accept keys/values that are not strictly the AA's key/value type, but can be implicitly converted to them. It lets you return keys and values without needing the ugly typeinfo and void* casts that are necessary in aaA.d. This in turn lets you mark many AA methods as pure, and almost all as safe or trusted. It lets you cleanly interoperate with types that define opAssign (currently aaA.d does a blind binary copy of data from key/value pointers, which leads to potential bugs when the data has subobjects.) It also makes it *much* easier to fix many existing AA bugs in the bugtracker. So far, I have working unittests for the following issues: 3824, 3825, 4337, 4463, 5685, 6210, 7512, 7512, 7602, 7632, 7665, 7665, 7704. I haven't looked through all AA-related issues yet; this list may very well grow. :-) To fix these in the current aaA.d implementation can be rather tricky, and quite possibly requires compiler changes. Better yet, I thought of a way of making AA's instantiable at compile-time via CTFE and mixins: this will let you write AA literals that can be evaluated at compile-time and have them turn into object code directly without needing runtime initialization. Another major benefit is that once the AA implementation is decoupled from the compiler (the compiler will only provide syntactic sugar like V[K] and literal syntax), we can finally fix AA bugs without getting roadblocked by compiler limitations or hard-to-repair compiler design flaws (or dirty hacks in the compiler that were introduced to paper over the fundamental schizophrenic problem of struct AssociativeArray being distinct yet not different from the AA implementation in aaA.d). Things are MUCH easier to fix when you can directly access key/value types instead of having only TypeInfo's and needing to resort to void* casting. [...]
 C++ ctors are a royal pain in the neck. [...]
 I ended up using just stub ctors for a lot of my code, and doing the
 actual initialization after the object is constructed. Which is very
 bad OO style, I agree, but the pain of working with C++ ctors just
 pushes me in the wrong direction, y'know?

Yea, that's what I've been planning on doing with the C++ stuff I have coming up. Don't even want to bother with C++'s ctor limitations. Just make an init() member and be done with it. Actually, that seems to be turning into more and more of a common C++ idiom though, from what (little) I've seen.

The fact that C++ is pushing people in that direction is scary. It breaks one of the principles of good object design, which is that all sequences of method calls should never cause it to enter into an inconsistent state. This no longer holds if init() has to be called first. This is a sign that something is fundamentally wrong with the language.
 [...] (And even finally: I head somewhere C++ doesn't even have
 finally: Is that true?!?)

Yes, it's true. I don't know about C++11, but certainly the previous standard has no finally clause, leading to horribly unmaintainable and ugly code like: Resource r = acquireResource(); try { doSomethingDangerous(); } catch(...) { r.release(); } r.release();

Haxe also lacks finally! Which I always found rediculous. So yea, I'm intimately familiar with that idiom. I've used it myself far more than I would like.

And actually there's already a bug in the code I wrote: I forgot the rethrow inside the catch(...). See, that's how bug-prone this stupid idiom is.
 And even *that* still doesn't work if you don't catch *every*
 exception (and then rethrow the ones you don't care about? Ick!).

Actually, you can catch "..." and it will catch *everything*. And I believe a single "throw;" will rethrow whatever it is you caught.
 I've seen C++ programmers swear off exceptions because of this, and I
 can't blame them at all.  Exception systems *need* a finally.

Yeah. "catch(...)" sorta works, but it's very ugly. And while being able to throw *anything* at all is nice (I'm guilty of writing code that throws char*, for example), not being able to make *any* assumptions at all about what you caught (e.g., no common exception superclass with some useful methods, like .msg) is, shall we say, practically useless in a large enough project? (Actually, the lack of .msg was what drove me to throw char*. Obviously checking return codes for every lousy function I call is out of the question, but so is throwing error codes that come from different subsystems, since you've no way of telling which error code scheme to use to look up the error. So I said to myself, why not throw a string that actually tells you what the error is? Furthermore, if these strings were predefined in char arrays that had unique pointer addresses, the value of the pointer itself serves as a kind of "global error number". So this worked as a kind of a poor man's error code + message exception that can be freely thrown around without problems --- the reason I shied away from throwing class objects in the first place was because early implementations of C++ had problems that sometimes caused pointer bugs and all kinds of nasty side effects when a class object is thrown. Like if you forget to define a copy ctor for your exception class, and you forget to catch by reference instead of by value... With a char*, there can be no such problem unless the compiler is completely unusable.) [...]
 For all the warts the current GC has, the fact that D has a GC at
 all makes things like array slicing possible, and *fast*, which
 leads to all the other niceties of slicing.

I used to do indie game dev in C/C++ and I feel downright spoiled now with tossing in a "new" whenever appropriate and not have to worry about cleanup (and even that wouldn't be *too* bad...in certain cases...if there were at least scope guards).

Scope guards rule. Ironically, D's GC mostly alleviates the need for scope guards. :-) They're still immensely useful when you acquire resources that must be cleaned up no matter what happens later. D is the first and only language I know that got resource cleanup done right. Cleanups belong with the acquisition code, not dangling somewhere 200 lines down at the end of the scope, with who knows how many possible leaks in between due to goto's, exceptions, returns, and who knows what! [...]
 Definitely. Using alias and static if in a recursive template is one
 of the hallmarks of the awesomeness of D templates.

I'd say one of the hallmarks of D's metaprogramming is the enormous *decrease* in the need for recursive templates in the first place ;)

CTFE even makes it possible to express what many recursive templates express, in pure imperative style. I mean, you can't get any better than this: int factorial(int n) { int result = 1; while (n>1) { result *= n; result--; } return result; } enum x = factorial(12); // compile-time computation int y = factorial(12); // runtime computation In C++, you'd have to use recursive templates that are extremely difficult to read and write beyond the simplest of functions.
 With C++'s templates, it would appear that you have to use recursion
 and helper templates for damn near anything.

Not to mention the horrible, horrible, syntax that comes with recursive templates. My previous manager used to tell me that as soon as he sees nested templates deeper than 2 levels, his eyes start glazing over, and it all becomes just arcane black magic. T -- Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert
Mar 20 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.949.1332305140.4860.digitalmars-d puremagic.com...
 Yeah, AA's with int keys are like arrays enhanced with O(1)
 insertion/removal and sparse storage (if you have very large indices,
 e.g.). :-) You can even have (pseudo) linear access if you iterate keys
 from 0 to $.

Exactly.
 For example, it lets you accept keys/values that are not strictly the
 AA's key/value type, but can be implicitly converted to them. It lets
 you return keys and values without needing the ugly typeinfo and void*
 casts that are necessary in aaA.d.  This in turn lets you mark many AA
 methods as pure, and almost all as  safe or  trusted. It lets you
 cleanly interoperate with types that define opAssign (currently aaA.d
 does a blind binary copy of data from key/value pointers, which leads to
 potential bugs when the data has subobjects.)

 It also makes it *much* easier to fix many existing AA bugs in the
 bugtracker. So far, I have working unittests for the following issues:
 3824, 3825, 4337, 4463, 5685, 6210, 7512, 7512, 7602, 7632, 7665, 7665,
 7704. I haven't looked through all AA-related issues yet; this list may
 very well grow. :-) To fix these in the current aaA.d implementation can
 be rather tricky, and quite possibly requires compiler changes.

I see. Cool stuff.
 Better yet, I thought of a way of making AA's instantiable at
 compile-time via CTFE and mixins: this will let you write AA literals
 that can be evaluated at compile-time and have them turn into object
 code directly without needing runtime initialization.

Ah! Now *that's* fucking awesome! That limitation has kinda stuck out as an odd, annoying wart.
 And even *that* still doesn't work if you don't catch *every*
 exception (and then rethrow the ones you don't care about? Ick!).

Actually, you can catch "..." and it will catch *everything*. And I believe a single "throw;" will rethrow whatever it is you caught.

I see. It has been awhile since I've been in the C++ loop.
 I've seen C++ programmers swear off exceptions because of this, and I
 can't blame them at all.  Exception systems *need* a finally.

Yeah. "catch(...)" sorta works, but it's very ugly. And while being able to throw *anything* at all is nice (I'm guilty of writing code that throws char*, for example), not being able to make *any* assumptions at all about what you caught (e.g., no common exception superclass with some useful methods, like .msg) is, shall we say, practically useless in a large enough project?

Boy, it really has been awhile. I knew you could throw any class object in C++, but I thought that was all. Haxe lets you throw literally anything, even Int, and I found that to be more of a problem than a feature (In very much the same way as VB's ability to change the lower bound of an array: It gains little and just means you have to remember to do the rediculous "UBound(arr) - LBound(arr)".) Just have a proper Exception class and nothing else should be throwable (D's "Error" notwithstanding).
 (Actually, the lack of .msg was what drove me to throw char*. Obviously
 checking return codes for every lousy function I call is out of the
 question, but so is throwing error codes that come from different
 subsystems, since you've no way of telling which error code scheme to
 use to look up the error. So I said to myself, why not throw a string
 that actually tells you what the error is? Furthermore, if these strings
 were predefined in char arrays that had unique pointer addresses, the
 value of the pointer itself serves as a kind of "global error number".
 So this worked as a kind of a poor man's error code + message exception
 that can be freely thrown around without problems

That is an interesting work around.
 the reason I shied
 away from throwing class objects in the first place was because early
 implementations of C++ had problems that sometimes caused pointer bugs
 and all kinds of nasty side effects when a class object is thrown.

Ouch!
 Scope guards rule. Ironically, D's GC mostly alleviates the need for
 scope guards. :-) They're still immensely useful when you acquire
 resources that must be cleaned up no matter what happens later. D is the
 first and only language I know that got resource cleanup done right.
 Cleanups belong with the acquisition code, not dangling somewhere 200
 lines down at the end of the scope, with who knows how many possible
 leaks in between due to goto's, exceptions, returns, and who knows what!

I've even come across at least a couple uses of scope guard that aren't strictly related to releasing resources. Actually, I've just been working with both of them today: - Temporarily changing a value: int bar; void foo() { // Change bar temporarily auto saveBar = bar; bar = 777; scope(exit) bar = saveBar; [...do anything here...] } - Timing a section of code. I saw this trick in someone else's code once, loved it, and made a helper tool out of it: https://bitbucket.org/Abscissa/semitwistdtools/src/4455e019cd95/src/semitwist/util/mixins.d#cl-643 It's a string mixin that, after features and hygenic issues and such, basically boils down to mixing in this psuedo-code: if(verbose) { write(customMessage, "..."); // no newline stdout.flush(); startTimer(); // Using the awesome new std.datetime } scope(exit) if(verbose) writeln(timerInMilliseconds(), "ms");
 CTFE even makes it possible to express what many recursive templates
 express, in pure imperative style. I mean, you can't get any better than
 this:

 int factorial(int n) {
 int result = 1;
 while (n>1) {
 result *= n;
 result--;
 }
 return result;
 }
 enum x = factorial(12); // compile-time computation
 int y = factorial(12); // runtime computation

 In C++, you'd have to use recursive templates that are extremely
 difficult to read and write beyond the simplest of functions.

Yup exactly. It's Haskell with bad syntax and compile times. Not only that, but even something as trivial as "if" has to be built out of pure-fp primitives in C++-template-land, whereas D just has: "static if...done!" Of course, to C++'s credit, its templates (AIUI) weren't really designed for metaprogramming, just for generics. The metaprogramming was just a happy accident (At least that's my understanding, maybe I'm wrong...)
 With C++'s templates, it would appear that you have to use recursion
 and helper templates for damn near anything.

Not to mention the horrible, horrible, syntax that comes with recursive templates. My previous manager used to tell me that as soon as he sees nested templates deeper than 2 levels, his eyes start glazing over, and it all becomes just arcane black magic.

Yea. Even a "simpler" use of C++'s templates can feel like staring into the depths of hell: Ever see a loop over a collection using STL iterators? Sheesh. I like the idea behind the STL, but with syntax like that I'd rather use the old "for(int i=0; i<theEnd; i++)". Gimme a proper foreach anyday. Come to think of it, foreach probably fits the bill for the OP: For people who came from C/C++ like I did, it can seem like a relatively trivial sugar over "for(int i=0; i<theEnd; i++)". But it makes such a difference to just not have to constantly deal with those minute mechanics.
 -- 
 Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich 
 Schubert

lol :) Now that's without a doubt one of my favorites.
Mar 21 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/21/2012 1:01 AM, Nick Sabalausky wrote:
 Of course, to C++'s credit, its templates (AIUI) weren't really designed for
 metaprogramming, just for generics. The metaprogramming was just a happy
 accident (At least that's my understanding, maybe I'm wrong...)

You're correct. Metaprogramming was an emergent property of C++ templates, and was discovered, not designed.
Mar 21 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--f46d04083be935356304bbba6d58
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 20, 2012 at 10:47 PM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

[snip]

I would say the main benefit is having it implemented in the library,
 because that allows the implementation have direct access to key/value
 types. I didn't implement any clever new hashing algorithm at all, I
 just mainly followed the implementation in aaA.d. But having direct
 access to key/value types is a *huge* win.

 For example, it lets you accept keys/values that are not strictly the
 AA's key/value type, but can be implicitly converted to them. It lets
 you return keys and values without needing the ugly typeinfo and void*
 casts that are necessary in aaA.d.  This in turn lets you mark many AA
 methods as pure, and almost all as  safe or  trusted. It lets you
 cleanly interoperate with types that define opAssign (currently aaA.d
 does a blind binary copy of data from key/value pointers, which leads to
 potential bugs when the data has subobjects.)

important issues you're addressing but have you given much thought to improving the hashing function? I haven't hit any issues with the speed of the current hasher but better performance is always welcome. MurmurHash seems to be all the rage these days with a lot of languages and systems adopting it <http://en.wikipedia.org/wiki/MurmurHash> (it compiles down to ~52 instructions on x86). It'd be interesting to see benchmarks with it. I'm not sure where the current hashing function lives to see what it's like. Regards, Brad Anderson --f46d04083be935356304bbba6d58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2012 at 10:47 PM, H. S. Teoh <span dir=3D"ltr">&lt;<a href= =3D"mailto:hsteoh quickfur.ath.cx">hsteoh quickfur.ath.cx</a>&gt;</span> wr= ote:<div><br></div><div>[snip]</div><div><br><div class=3D"gmail_quote"><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"> I would say the main benefit is having it implemented in the library,<br> because that allows the implementation have direct access to key/value<br> types. I didn&#39;t implement any clever new hashing algorithm at all, I<br=

access to key/value types is a *huge* win.<br> <br> For example, it lets you accept keys/values that are not strictly the<br> AA&#39;s key/value type, but can be implicitly converted to them. It lets<b= r> you return keys and values without needing the ugly typeinfo and void*<br> casts that are necessary in aaA.d. =A0This in turn lets you mark many AA<br=

cleanly interoperate with types that define opAssign (currently aaA.d<br> does a blind binary copy of data from key/value pointers, which leads to<br=

<br></blockquote><div><br></div><div>It&#39;s probably far too early to thi= nk about this with all the other important issues you&#39;re addressing but= have you given much thought to improving the hashing function? =A0I haven&= #39;t hit any issues with the speed of the current hasher but better perfor= mance is always welcome. MurmurHash seems to be all the rage these days wit= h a lot of languages and systems adopting it &lt;<a href=3D"http://en.wikip= edia.org/wiki/MurmurHash">http://en.wikipedia.org/wiki/MurmurHash</a>&gt; (= it compiles down to ~52 instructions on x86). It&#39;d be interesting to se= e benchmarks with it. I&#39;m not sure where the current hashing function l= ives to see what it&#39;s like.</div> <div><br></div><div>Regards,</div><div>Brad Anderson</div></div></div> --f46d04083be935356304bbba6d58--
Mar 20 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-20 23:58, Nick Sabalausky wrote:
 - Type inference
 - alias
 - foreach
 - Everything about arrays/slices
 - Built-in associative arrays that support nearly any type as a key
 - Reference semantics for classes
 - All the niceities of ctors compared with C++'s ctors
 - Backtick strings
 - Scope guards (And even finally: I head somewhere C++ doesn't even have
 finally: Is that true?!?)
 - GC
 - Name any of D's metaprogramming features

 Many of those can seem like simple things, but I'd *hate* to have to get by
 without them. Heck, most of them I now take for granted.

 Alias in particular is a much bigger deal than it seems since it's seemingly
 trivial but can be *incredibly* helpful with templates *and* with importing.

 Actually, looking at this list, I'm now starting to get a little worried
 about an upcoming C++ project... No doubt I'll be trying to reinvent a lot
 of D in it. Probably in ugly hackish ways.

I did that in one project. I emulated properties, using boost I emulated foreach, auto, lambdas and other features. If you're using C++11 you'll have these features native, expect for properties. I did the mistake and learned D before I learned C++. -- /Jacob Carlborg
Mar 21 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 It's probably far too early to think about this with all the other
 important issues you're addressing but have you given much thought to
 improving the hashing function?  I haven't hit any issues with the speed  
 of
 the current hasher but better performance is always welcome. MurmurHash
 seems to be all the rage these days with a lot of languages and systems
 adopting it <http://en.wikipedia.org/wiki/MurmurHash> (it compiles down  
 to
 ~52 instructions on x86). It'd be interesting to see benchmarks with it.
 I'm not sure where the current hashing function lives to see what it's  
 like.

 Regards,
 Brad Anderson

More throughput but higher latency. http://codepad.org/kCVQ8eoq Murmurhash was a little slower than CityHash but both are a little expensive for very few bytes.
Mar 21 2012
prev sibling next sibling parent "Patrick Down" <patrick.down gmail.com> writes:
On Wednesday, 21 March 2012 at 02:47:20 UTC, Walter Bright wrote:
 Andrei discovered an amazing use of auto. It enables you to 
 create variables with voldemort types "that may not be named".

+1 LOL for Voldemort types
Mar 21 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--bcaec55401a6ba32b704bbc2d80f
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 21, 2012 at 2:06 AM, Martin Nowak <dawg dawgfoto.de> wrote:

 It's probably far too early to think about this with all the other
 important issues you're addressing but have you given much thought to
 improving the hashing function?  I haven't hit any issues with the speed
 of
 the current hasher but better performance is always welcome. MurmurHash
 seems to be all the rage these days with a lot of languages and systems
 adopting it <http://en.wikipedia.org/wiki/**MurmurHash<http://en.wikipedia.org/wiki/MurmurHash>>
 (it compiles down to
 ~52 instructions on x86). It'd be interesting to see benchmarks with it.
 I'm not sure where the current hashing function lives to see what it's
 like.

 Regards,
 Brad Anderson

More throughput but higher latency. http://codepad.org/kCVQ8eoq Murmurhash was a little slower than CityHash but both are a little expensive for very few bytes.

Interesting. Thanks for the link. Regards, Brad Anderson --bcaec55401a6ba32b704bbc2d80f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 21, 2012 at 2:06 AM, Martin Nowak <span dir=3D"ltr">&lt;<a href= =3D"mailto:dawg dawgfoto.de">dawg dawgfoto.de</a>&gt;</span> wrote:<br><div= class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"> It&#39;s probably far too early to think about this with all the other<br> important issues you&#39;re addressing but have you given much thought to<b= r> improving the hashing function? =A0I haven&#39;t hit any issues with the sp= eed of<br> the current hasher but better performance is always welcome. MurmurHash<br> seems to be all the rage these days with a lot of languages and systems<br> adopting it &lt;<a href=3D"http://en.wikipedia.org/wiki/MurmurHash" target= =3D"_blank">http://en.wikipedia.org/wiki/<u></u>MurmurHash</a>&gt; (it comp= iles down to<br> ~52 instructions on x86). It&#39;d be interesting to see benchmarks with it= .<br> I&#39;m not sure where the current hashing function lives to see what it&#3= 9;s like.<br> <br> Regards,<br> Brad Anderson<br> </blockquote> <br></div> More throughput but higher latency.<br> <a href=3D"http://codepad.org/kCVQ8eoq" target=3D"_blank">http://codepad.or= g/kCVQ8eoq</a><br> Murmurhash was a little slower than CityHash but<br> both are a little expensive for very few bytes.<br> </blockquote></div><br><div>Interesting. =A0Thanks for the link.</div><div>= <br></div><div>Regards,</div><div>Brad Anderson</div> --bcaec55401a6ba32b704bbc2d80f--
Mar 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 20, 2012 at 11:54:37PM -0600, Brad Anderson wrote:
[...]
 It's probably far too early to think about this with all the other
 important issues you're addressing but have you given much thought to
 improving the hashing function?  I haven't hit any issues with the
 speed of the current hasher but better performance is always welcome.
 MurmurHash seems to be all the rage these days with a lot of languages
 and systems adopting it <http://en.wikipedia.org/wiki/MurmurHash> (it
 compiles down to ~52 instructions on x86). It'd be interesting to see
 benchmarks with it.  I'm not sure where the current hashing function
 lives to see what it's like.

The current implementation actually has (at least) two different hash functions: - Paul Hsieh's SuperFastHash (rt.util.hash.hashOf) - A custom hash for char[] and string: look in rt/typeinfo/ti_Ag.d for class TypeInfo_Aa, which has this: hash_t hash = 0; foreach (char c; s) hash = hash * 11 + c; I'm going to benchmark both hash functions to see which is actually faster. I suspect the custom hash is faster for small strings, though it may not have good hash distribution. T -- Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.
Mar 21 2012
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Mar 20, 2012, at 10:54 PM, Brad Anderson wrote:
=20
 It's probably far too early to think about this with all the other =

improving the hashing function? I haven't hit any issues with the speed = of the current hasher but better performance is always welcome. = MurmurHash seems to be all the rage these days with a lot of languages = and systems adopting it <http://en.wikipedia.org/wiki/MurmurHash> (it = compiles down to ~52 instructions on x86). It'd be interesting to see = benchmarks with it. I'm not sure where the current hashing function = lives to see what it's like. Druntime actually did use MurmurHash for a while and then dropped it = because the site had no copyright license for the code (a mistake that = has since been rectified). I'd consider switching back, though I don't = really like that MurmurHash has a number of separate implementations = targeted at different platforms, each having different performance = characteristics. It's 4x faster than SuperFastHash on x86 but 10x = slower than SuperFastHash on SPARC, for example.=
Mar 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"Sean Kelly" <sean invisibleduck.org> wrote in message 
news:mailman.981.1332359368.4860.digitalmars-d puremagic.com...
Druntime actually did use MurmurHash for a while and
then dropped it because the site had no copyright license
for the code (a mistake that has since been rectified).  I'd
consider switching back, though I don't really like that
MurmurHash has a number of separate implementations
targeted at different platforms, each having different
performance characteristics.  It's 4x faster than SuperFastHash
on x86 but 10x slower than SuperFastHash on SPARC,
for example.=

People still use SPARC? /me out of the loop
Mar 21 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Mar 21, 2012, at 2:18 PM, Jacob Carlborg wrote:

 On 2012-03-21 20:49, Sean Kelly wrote:
=20
 Druntime actually did use MurmurHash for a while and then dropped it =


has since been rectified). I'd consider switching back, though I don't = really like that MurmurHash has a number of separate implementations = targeted at different platforms, each having different performance = characteristics. It's 4x faster than SuperFastHash on x86 but 10x = slower than SuperFastHash on SPARC, for example.
=20
 Would it be possible to use different algorithms on different =

Depends whether there's any reason to have different platforms attempt = to generate the same hash for a given input.=
Mar 21 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 21, 2012 at 10:18:16PM +0100, Jacob Carlborg wrote:
 On 2012-03-21 20:49, Sean Kelly wrote:
 
Druntime actually did use MurmurHash for a while and then dropped it
because the site had no copyright license for the code (a mistake
that has since been rectified).  I'd consider switching back, though
I don't really like that MurmurHash has a number of separate
implementations targeted at different platforms, each having
different performance characteristics.  It's 4x faster than
SuperFastHash on x86 but 10x slower than SuperFastHash on SPARC, for
example.

Would it be possible to use different algorithms on different platforms?

Should be as simple as adding version() to rt.util.hash.hashOf, I think. But I don't know if there may be potential issues with that. T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
Mar 21 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 20, 2012 at 06:58:31PM -0400, Nick Sabalausky wrote:
 - Type inference

Yeah I forgot about this one. Being able to write: auto veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); is a big boon over C++ or Java's stuttering verbosity: VeryLongNamedClass veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); Plus, it's immensely useful when dealing with Range templates... can you imagine the horrifically long typenames you'd have to type you have to explicitly specify the type of a long chain of functional expressions involving 15+ std.algorithm and std.range templates?
 - alias

This, together with static ifs and templates, make for awesome tricks involving templates that would've been an utter bear to pull off in C++. template innerKeyType(T) { static if (is(T U : U[K], K)) alias innerKeyType!K innerKeyType; else alias T innerKeyType; } innerKeyType!(int[string[char[byte]]]) innerKey; [...]
 - Built-in associative arrays that support nearly any type as a key

This is actually quite buggy right now... but that's merely an implementation issue. :-) My new AA implementation, for example, already correctly supports AA's with AA keys, which can be arbitrarily nested. So you could have something like int[string[char[byte]]], and it does lookups correctly based on the contents of the AA's you pass in as key.
 - All the niceities of ctors compared with C++'s ctors

C++ ctors are a royal pain in the neck. I remember in the early days of C++ when you can still call the base class ctor in the body of the derived class ctor... nowadays you have to contort ctor code into a horrible ugly mess just to get your ctor to do things right. Plus, the C++ standard requires fields to be initialized in declaration order, which is needlessly restrictive and basically makes ctors even more of a pain. I ended up using just stub ctors for a lot of my code, and doing the actual initialization after the object is constructed. Which is very bad OO style, I agree, but the pain of working with C++ ctors just pushes me in the wrong direction, y'know?
 - Scope guards (And even finally: I head somewhere C++ doesn't even have 
 finally: Is that true?!?)

Yes, it's true. I don't know about C++11, but certainly the previous standard has no finally clause, leading to horribly unmaintainable and ugly code like: Resource r = acquireResource(); try { doSomethingDangerous(); } catch(...) { r.release(); } r.release(); (Yes, yes, I know, RAII and all that... which leads to inventing ridiculous classes which make no sense in terms of OO, just to wrap resource handles.)
 - GC

For all the warts the current GC has, the fact that D has a GC at all makes things like array slicing possible, and *fast*, which leads to all the other niceties of slicing.
 - Name any of D's metaprogramming features

 Alias in particular is a much bigger deal than it seems since it's
 seemingly trivial but can be *incredibly* helpful with templates *and*
 with importing.

Definitely. Using alias and static if in a recursive template is one of the hallmarks of the awesomeness of D templates.
 Actually, looking at this list, I'm now starting to get a little worried 
 about an upcoming C++ project... No doubt I'll be trying to reinvent a lot 
 of D in it. Probably in ugly hackish ways.

#include "dmd.h" ;-) T -- Don't modify spaghetti code unless you can eat the consequences.
Mar 20 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
What you might want to do is look back at
early ng posts about features and see which
ones were met with "meh", but universally
considered to rok now.

Asking for stuff now will be hard to be
unbiased on the surprise issue.


If my memory serves, a few things that were
"meh" when announced but that rok now are:

1) enum. I remember an argument over if we
should call it invariant, manifest, or the
relatively unpopular enum keyword, but I
don't recall people at the time expecting
it to be as useful as it is now.

The argument was between

manifest MY_VALUE = 1;
and
enum MY_VALUE = 1;

without thoughts along the line of:

template octal(...) {
     alias octalImpl(t) octal;
}

or most the other stuff we use ctfe with now.


(Speaking of octal, I remember that being dismisses
as a "hack" by some members too. Now, it looks like
that pattern is catching on for user defined literals,
and it rox.)


My memory might be bad, but looking at some old posts
could confirm if the "unlikely success" label is warranted.




2) Leaving the parenthesis off of simple template
instantiations is something I was against early on,
and now I love it.

IIRC, you wanted to use a different symbol entirely,
and leaving the parens off was a compromise between
the radical Unicode character proposal and Walter's
conservative parenthesis.



This is a really small change. At the time, it seemed
like it would be stupid and useless.



But, would templates be as popular now if we didn't
make this change?

auto a = to!(int)("10");

vs

auto a = to!int("10");



to!int feels like one word, unlike to!(int)().
Who needs atoi when we can say to!int?


Decls too: Appender!int, etc. The popularity of
this in phobos and outside speaks to a success
I didn't expect.



3) My mind is coming up blank on a third newsgroup argument
over an awesome feature we use now. But, something I
am often amazed about is how cool structs are.

When you say "struct", I used to think of "whoo a collection
of vars, big deal".

But, now, with D2, when you say "struct", I think "fully
customizable powerhouse".

(even coming from C++, where much of this can be done, D's
structs are still a little mindblowing in comparison.)
Mar 20 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:txwnbkafemkurcqjermf forum.dlang.org...
 2) Leaving the parenthesis off of simple template
 instantiations is something I was against early on,
 and now I love it.

 IIRC, you wanted to use a different symbol entirely,
 and leaving the parens off was a compromise between
 the radical Unicode character proposal and Walter's
 conservative parenthesis.

 This is a really small change. At the time, it seemed
 like it would be stupid and useless.

Yea, that's a good one. I seem to remember initally thinking that it felt sloppy, but I was otherwise relatively indifferent about it. But now I absolutely love it...sooo much.
 But, would templates be as popular now if we didn't
 make this change?

 auto a = to!(int)("10");

 vs

 auto a = to!int("10");

Exactly. Ooh, nested functions and closures are another good one (or two). I get so much use of of those. Speaking of, here's a good one (IMO): The syntax for delegate types (as opposed to C's crude function pointer syntax). A small change, but really helps open up the world of first-class functions, even just by itself.
Mar 20 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/21/2012 7:23 AM, Adam D. Ruppe wrote:
 But, is import unlikely success, or is this just a
 leftover feeling from my massive bias in the early
 days? I have to say it is my bias, since everyone
 else uses import and they all know it is good.

I knew import would be good :-) It's because I've used languages before with an import, and as a compiler guy, I knew what a kludge #include is. The preprocessor in C/C++ is a crutch to make up for deficiencies in the language.
Mar 21 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-21 18:20, Walter Bright wrote:

 I knew import would be good :-)

 It's because I've used languages before with an import, and as a
 compiler guy, I knew what a kludge #include is. The preprocessor in
 C/C++ is a crutch to make up for deficiencies in the language.

I've never been able to properly handle includes in C/C++. Import is SO much better. -- /Jacob Carlborg
Mar 21 2012
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Kapps" <opantm2+spam gmail.com> wrote in message 
news:nnqtlpjqwdnzuwiqcycr forum.dlang.org...
 On Wednesday, 21 March 2012 at 17:20:28 UTC, Walter Bright wrote:
 On 3/21/2012 7:23 AM, Adam D. Ruppe wrote:
 But, is import unlikely success, or is this just a
 leftover feeling from my massive bias in the early
 days? I have to say it is my bias, since everyone
 else uses import and they all know it is good.

I knew import would be good :-) It's because I've used languages before with an import, and as a compiler guy, I knew what a kludge #include is. The preprocessor in C/C++ is a crutch to make up for deficiencies in the language.

On the topic of import, mixin imports are something that I believe will eventually become a great deal more popular than they are today. First, there's the advantage of being able to use a language/syntax more appropriate for the task at hand. For example, for things that output html you could just import mixin a raw html file. But the real advantage is that you can still do compile-time processing on this. Plug in an xml parser, or something like pegged, and you can now extend Html and generate D code for it. For example, if you have something like runat="server" on an element, just like in ASP.net you could create a serverside element for this and manipulate it. Because you know exactly which parts are static and which are dynamic, you could (at compile time) create buffers containing the static portions to prevent having to copy things many times. Unlike other languages, there would be no performance hit to doing this because it's all done at compile time. This is just one example. Another one would be automatically creating bindings for a scripting language, or even automatically creating bindings for a C header file.

Oh yea, definitely. I'm already using HTML mixin imports for the little bit of sever-side web stuff I've started playing around with in D.
Mar 21 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"F i L" <witte2008 gmail.com> wrote in message 
news:sofbqiiyvragxjaxqbix forum.dlang.org...
 Kapps wrote:
 or even automatically creating bindings for a C header file.

I've thought about that before. It would be great to have fully automatic linking to C libs. You could even have a cache system that stores .di files and only regenerates them if the .h file was modified.

That hits on the one irritating limitation of CTFE: No I/O. So that cache system would be a no-go right now.
Mar 21 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/21/2012 10:37 PM, Nick Sabalausky wrote:
 "F i L"<witte2008 gmail.com>  wrote in message
 news:sofbqiiyvragxjaxqbix forum.dlang.org...
 Kapps wrote:
 or even automatically creating bindings for a C header file.

I've thought about that before. It would be great to have fully automatic linking to C libs. You could even have a cache system that stores .di files and only regenerates them if the .h file was modified.

That hits on the one irritating limitation of CTFE: No I/O. So that cache system would be a no-go right now.

I once cached CTFE results by wrapping some templates into another template that would generate pragma(msg, ...) output that was then fitered out by an external d program and written to temporary files. On the next compilation run, the wrapper template would notice the existence of a suitable cache file and use its contents instead of starting the CTFE execution.
Mar 21 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-21 22:32, F i L wrote:
 Kapps wrote:
 or even automatically creating bindings for a C header file.

I've thought about that before. It would be great to have fully automatic linking to C libs. You could even have a cache system that stores .di files and only regenerates them if the .h file was modified.

I've been thinking on that as well since I'm writing a tool for converting header files. But I was thinking more of modifying the compiler and adding a new pragma that calls into my library. -- /Jacob Carlborg
Mar 21 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:vuegxcpcbsefvmjdqesp forum.dlang.org...
 On Wednesday, 21 March 2012 at 21:01:10 UTC, Kapps wrote:
 On the topic of import, mixin imports are something that I believe will 
 eventually become a great deal more popular than they are today.

I use a *lot* of import() (one of my work projects imports() about 140 files!) but I fairly rarely use mixin with it. What I love about it is simply having a one-piece executable. All your default data is right there. Deployment is easy. If replacement files exist at runtime, you might use them, but if not, you always have a default built in! It is much easier than external resource files, and being able to process is a nice win.

Yea. It especially would have been great back when I was doing GBA homebrew. With that stuff having been in C/C++, just to include *any* real binary data, we had to use external tools (as a pre-compilation build step) to convert the binary data files into C files that contained "char myData[] = [0x01, 0x5B, 0xFF, 0x80, ...];" (or something like that - my C muscles have atrophied). And then later on someone made sort of a mini file-system where you could add data to a ROM image and then query/access it from your code in the ROM. If we had been doing things in D, we could all have just typed import("myData.dat") and been *done*. None of those extra tools or MIME-like-bloating^H^H^H^H^H^H^H^Hencoding bullshit.
Mar 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:oyqxvngsgjfmrlrwhohf forum.dlang.org...
 On Thursday, 22 March 2012 at 04:49:24 UTC, Nick Sabalausky wrote:
 And then later on someone made sort of a mini file-system where you could 
 add data to a ROM
 image and then query/access it from your code

Now, this reminds me, what if you want to access the compile time files from runtime? For instance, one of my projects lets you include other files in the html. (Something I actually don't like, but it is an easy crutch.) You can also replace these at runtime, so the other team members can change stuff without access to the compiler. Here's what I ended up writing: // filesystem alternatives... string getFile(string name)() { if(std.file.exists(dir ~ name)) return std.file.readText(dir ~ name); else return import(name); } // runtime fetching string getIncludeFile(string name) { enum manifest = ["file1.html", "file2.html", ......]; string manifests() { string cases; foreach(f; manifest) cases ~= "case \""~f~"\": return getFile!(\""~f~"\");"; return cases; } switch(name) { default: assert(0, name); mixin(manifests()); } } I'm a bit disappointed that I needed a list of files duplicated there. With import(), if it is in the import directory, it just works, but then the name must be known at compile time. This is the best I have so far... and i like it, but it isn't quite ideal yet.

Clever idea, I like it.
Mar 22 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:fuxnqnmrskrfqqmhdjws forum.dlang.org...
 Nested functions, auto, and scope guards were the
 three killers in the pre-D1 that roped me in. And
 they rok, oh they rok. But that is "likely success" :)

The main thing that grabbed me in the pre-D1 days was the lack of header files in a non-VM systems langauge. Everything else was icing on the cake. Although, while it wasn't a major selling point in and of itself, the ability to put underscores in numeric literals *really* helped tell me, "Now *this* is a language that's very well thought out and values pragmatism." And *that* was the other main thing about D that grabbed me.
 One that surprised me personally though is import. Indeed,
 import is why I passed over D the first time I looked
 at it (in 2004 IIRC) - I saw "import" and said "gah
 include is fine, eff this Java like poo..

Heh, really? I started getting tired of C++ around 2002-ish, and around the same time, some college courses I was taking were introducing me to Java. I was never a fan of Java overall, and there's a lot about it I always *hated*, but the lack of header files was one thing that *did* really impress me about Java (the other things were reference semantics for classes and GC). It was enough that, at the time, I considered it a reasonable alternative to C++ for things that didn't need number crunching, high performance or low-level access - at least until I discovered C# and D (eventually I got tired of C#'s limitations, too).
Mar 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:utkgtgcgguydxrabkily forum.dlang.org...
 But, eh, D pwns C++ in so many ways that while I still
 like C++, I'm no longer in the camp of "c++ is obviously
 great and totally sufficient and if you don't see it,
 you must be some kind of idiot" like I was for a while.

Heh, yea. I think in a way that's kind of the problem with C++: It can be technically considered "sufficient"...but that's it - it's *merely* sufficient. "Why have a Pop-Tart(tm) when you can have a warm delicious Pillsbury(tm) Toaster Strudel(tm)?" ;)
Mar 21 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 21 March 2012 at 00:53:19 UTC, Adam D. Ruppe wrote:
 template octal(...) {
     alias octalImpl(t) octal;
 }

LOL, I was bloviating about "enum" and ended up using "alias" here. alias rox too (which is a bit amazing, considering how simple it is), but I should have said: enum octal = octalImpl(t);
Mar 20 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 There are a few features of D that turned out to be successful, 
 in spite of them being seemingly unimportant or diverging from 
 related consecrated approaches.

 What are your faves?

After thinking some time about this, I can't find one of them :-) I see many useful/successful features in D, but none of them seemed unimportant at first to me. Maybe I am just strange, but very little of syntax and semantics of a language is unimportant. In languages even unused features (C trigraphs?) sometimes bite your bum, so they become important, with negative value. Bye, bearophile
Mar 20 2012
prev sibling next sibling parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu 
wrote:
 I plan to give a talk at Lang.NEXT 
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with 
 the subject above. There are a few features of D that turned 
 out to be successful, in spite of them being seemingly 
 unimportant or diverging from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to 
 influence answers.


 Thanks,

 Andrei

I've seen most of D's cool features mentioned, but I believe nobody mentioned mixins yet. Mixins are messy to maintain, but together with CTFE they can be used to create some really neat code if used properly. One of the first things I wrote while learning D is a vector class. In GLSL vectors can be 'swizzled', for example: vec3(1, 2, 3).zyx == vec3(3, 2, 1); Swizzles are often useful in graphics or physics code. I don't know of any non-shading language that allows me to use swizzle syntax. As the following code shows, it's quite easy to do in D: module main; import std.stdio; import std.process; import std.conv; int main(string[] argv) { alias Vec!4 Vec4; Vec4 v = Vec4(1, 2, 3, 4); writeln(v.bgra); // Prints Vec!(4)([3, 2, 1, 4]) writeln(v.rg); // Prints Vec!(2)([1, 2]) return 0; } private immutable (char[][]) elementNames = [['x', 'y', 'z', 'w'], ['r', 'g', 'b', 'a'], ['s', 't', 'p', 'q']]; struct Vec(size_t size) { alias size Size; mixin(generateConstructor(Size)); mixin(generateProperties(Size)); auto opDispatch(string s)() { mixin(generateSwizzle(s)); } float v[Size]; } private string generateConstructor(size_t size) { string constructorParams; string constructorBody; foreach(i; 0..size) { string paramName = "v" ~ to!string(i); constructorParams ~= "float " ~ paramName ~ "=0,"; constructorBody ~= "v[" ~ to!string(i) ~ "] = " ~ paramName ~ ";"; } return "this(" ~ constructorParams[0..$-1] ~ "){" ~ constructorBody ~ "}"; } private string generateProperties(size_t size) { string props; foreach(names; elementNames) { foreach(i, name; names[0..size]) { props ~= " property float " ~ name ~ "() const { return v[" ~ to!string(i) ~ "]; }"; props ~= " property void " ~ name ~ "(float f) { v[" ~ to!string(i) ~ "] = f; }"; } } return props; } private string generateSwizzle(string elements) { string swizzleImpl = "return Vec!" ~ to!string(elements.length) ~ "("; foreach(e; elements) { swizzleImpl ~= e ~ ","; } return swizzleImpl[0..$-1] ~ ");"; }
Mar 20 2012
prev sibling next sibling parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
And there goes the formatting, here's a pastebin version:
http://pastebin.com/dHdiG0ce

On Wednesday, 21 March 2012 at 01:41:27 UTC, Rene Zwanenburg 
wrote:
 On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu 
 wrote:
 I plan to give a talk at Lang.NEXT 
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) 
 with the subject above. There are a few features of D that 
 turned out to be successful, in spite of them being seemingly 
 unimportant or diverging from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want 
 to influence answers.


 Thanks,

 Andrei

I've seen most of D's cool features mentioned, but I believe nobody mentioned mixins yet. Mixins are messy to maintain, but together with CTFE they can be used to create some really neat code if used properly. One of the first things I wrote while learning D is a vector class. In GLSL vectors can be 'swizzled', for example: vec3(1, 2, 3).zyx == vec3(3, 2, 1); Swizzles are often useful in graphics or physics code. I don't know of any non-shading language that allows me to use swizzle syntax. As the following code shows, it's quite easy to do in D: module main; import std.stdio; import std.process; import std.conv; int main(string[] argv) { alias Vec!4 Vec4; Vec4 v = Vec4(1, 2, 3, 4); writeln(v.bgra); // Prints Vec!(4)([3, 2, 1, 4]) writeln(v.rg); // Prints Vec!(2)([1, 2]) return 0; } private immutable (char[][]) elementNames = [['x', 'y', 'z', 'w'], ['r', 'g', 'b', 'a'], ['s', 't', 'p', 'q']]; struct Vec(size_t size) { alias size Size; mixin(generateConstructor(Size)); mixin(generateProperties(Size)); auto opDispatch(string s)() { mixin(generateSwizzle(s)); } float v[Size]; } private string generateConstructor(size_t size) { string constructorParams; string constructorBody; foreach(i; 0..size) { string paramName = "v" ~ to!string(i); constructorParams ~= "float " ~ paramName ~ "=0,"; constructorBody ~= "v[" ~ to!string(i) ~ "] = " ~ paramName ~ ";"; } return "this(" ~ constructorParams[0..$-1] ~ "){" ~ constructorBody ~ "}"; } private string generateProperties(size_t size) { string props; foreach(names; elementNames) { foreach(i, name; names[0..size]) { props ~= " property float " ~ name ~ "() const { return v[" ~ to!string(i) ~ "]; }"; props ~= " property void " ~ name ~ "(float f) { v[" ~ to!string(i) ~ "] = f; }"; } } return props; } private string generateSwizzle(string elements) { string swizzleImpl = "return Vec!" ~ to!string(elements.length) ~ "("; foreach(e; elements) { swizzleImpl ~= e ~ ","; } return swizzleImpl[0..$-1] ~ ");"; }

Mar 20 2012
prev sibling next sibling parent "Jay Norwood" <jayn prismnet.com> writes:
On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu 
wrote:
 What are your faves? I have a few in mind, but wouldn't want to 
 influence answers.


 Thanks,

 Andrei

I'll have to say its whatever it is ( and I don't know what it is) that enabled that std.parallelism code to be written with such clean syntax and operate with such low overhead. You can explain what enabled both, I'm sure. Also I'm happy that the array operation syntax is included in the language.
Mar 20 2012
prev sibling next sibling parent "Joshua Niehus" <jm.niehus gmail.com> writes:
On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu 
wrote:
 What are your faves? I have a few in mind, but wouldn't want to 
 influence answers.

 Thanks,

 Andrei

1) inferred types (auto) 2) slices 3) whole > sum(mixin, opDispatch, static if)
Mar 20 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu
wrote:
 I plan to give a talk at Lang.NEXT 
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with 
 the subject above. There are a few features of D that turned 
 out to be successful, in spite of them being seemingly 
 unimportant or diverging from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to 
 influence answers.


 Thanks,

 Andrei

. ctfe - mixin . explain them why templates without "static if" is like a language without "if". . string, float and anything that matters can be used as template parameters.
Mar 21 2012
prev sibling next sibling parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu 
wrote:
 I plan to give a talk at Lang.NEXT 
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with 
 the subject above. There are a few features of D that turned 
 out to be successful, in spite of them being seemingly 
 unimportant or diverging from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to 
 influence answers.


 Thanks,

 Andrei

1. Compile time reflection This feature enables MessagePack to (de)serialize existing class and struct :) 2. Template friends Easy syntax, static if(and is), alias, mixin and other features are very useful. An essential parts ingredient to write D program. 3. Built-in array and slice I heavily use this feature in many cases. Template engine, complex computation and network programming :) Masahiro
Mar 21 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 21 March 2012 at 02:14:26 UTC, Nick Sabalausky 
wrote:
 Ooh, nested functions and closures are another good one (or 
 two).

I wouldn't call that unlikely, since nested functions are one of the things I considered a potential killer feature when I started with D. (and indeed, it is very useful!) Nested functions, auto, and scope guards were the three killers in the pre-D1 that roped me in. And they rok, oh they rok. But that is "likely success" :) (well, and fast compilation; going back to Digital Mars after some years of slow ass g++ was/is heaven) One that surprised me personally though is import. Indeed, import is why I passed over D the first time I looked at it (in 2004 IIRC) - I saw "import" and said "gah include is fine, eff this Java like poo.. Even when I got into D, I had to give myself comfort that I can still have #include with mixin(import()) - something I have never actually wanted to use after writing the first line of real code. import is amazing. D gets it all right, even with stuff like bug 314, it is awesome. But, is import unlikely success, or is this just a leftover feeling from my massive bias in the early days? I have to say it is my bias, since everyone else uses import and they all know it is good.
Mar 21 2012
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 20 Mar 2012 15:02:15 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 I plan to give a talk at Lang.NEXT  
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the  
 subject above. There are a few features of D that turned out to be  
 successful, in spite of them being seemingly unimportant or diverging  
 from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to  
 influence answers.

The two that I would cite are auto and slice syntax. I see others have chimed in with the same two. These were two features that did *not* attract me to D, but I found them to be two of my favorites, and ones I miss the most when writing in other languages. If I had to pick a third, I'd say the omitting parentheses for 1-arg templates was something I didn't expect to be as great as it is. Possibly one other thing I didn't expect to be so nice was shared (more specifically, the implications when something is *not* shared). That enabled weak-pure functions which I think are going to be a HUGE feature for D. -Steve
Mar 21 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/21/2012 7:45 AM, Steven Schveighoffer wrote:
 If I had to pick a third, I'd say the omitting parentheses for 1-arg templates
 was something I didn't expect to be as great as it is.

Yes, Andrei was the lone advocate of that for a while. Everyone else pooh-poohed it, including me.
Mar 21 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/21/12 12:26 PM, Walter Bright wrote:
 On 3/21/2012 7:45 AM, Steven Schveighoffer wrote:
 If I had to pick a third, I'd say the omitting parentheses for 1-arg
 templates
 was something I didn't expect to be as great as it is.

Yes, Andrei was the lone advocate of that for a while. Everyone else pooh-poohed it, including me.

I appreciate you implemented it in spite of not finding it compelling. Andrei
Mar 21 2012
prev sibling next sibling parent "pillsy" <pillsbury+dlist gmail.com> writes:
On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu 
wrote:

 There are a few features of D that turned out to be successful, 
 in spite of them being seemingly unimportant or diverging from 
 related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to 
 influence answers.

I know people have said all of these already, but I still want to vote for them, because they're so useful, and I routinely find myself wishing I had them in other languages. 1. Array slices. These allow for a lot of gains from structure sharing and "flyweighting"; safe structure sharing is one of the potential big wins from GC, but in most languages with GC it's tricky to share structure that's in arrays, leading to a lot of extra space overhead for pointers and worse cache behavior due to excessive scattering of objects around the heap. 2. Scope guard. At first I thought it was a neat little curiosity, but it makes it so easy to write and (more importantly) *read* error handling code that, whenever I use D, I find myself thinking about and dealing with potential failure modes that I would gloss over in another language. 3. Template syntax. When I first saw that it used an infix '!' of all things, and that the parentheses were optional, I thought it was the dumbest syntax ever. In practice, though, it's so much better than C++'s <> disaster that it's just not funny. A bunch of other features, like type inference, I totally expected to be extremely useful. The way auto lets you work with objects that have unutterable types is pretty cool, though I picked that up from the C++11 materials I've seen. They really need the feature to make the new lambdas work. Cheers, Pillsy
Mar 21 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Another feature I like a lot about D, is it's approach to nested 
classes. I'm not sure how it compares to other languages, but in 
C# nested classes can be instanced individually and therefor 
don't have access to their containing class's variables. D's 
approach is much more logical, and works great for simple state 
systems:

   abstract class Actor {
     interface State {
       void update();
     }
     State state;
     final void update() {
       assert(state, "State is null");
       state.update();
     }
   }

   class Fighter : Actor {
     Idle : State {
       void update() {
         punch(); // can punch automatically
       }
     }
     Idle idleState = new Idle();
     this() {
       state = idleState;
     }
     void punch() { ... }
   }

In C# I'd have to manually pass an Fighter reference to Idle's 
constructor and manually manage the reference. It's a small 
thing, but considering referencing the container class is a core 
mechanic of any Stated object, it's a pain having to rewrite it, 
while D just works.
Mar 21 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
And for my third favorite (in no order), I like custom 
allocators/deallocators. They're nice for creating "invisible" 
memory pools:

   static class Pool(T, uint size = 100) {
     static T[size] pool;
     static void* alloc() { ... }
     static void free(void* p) { ... }
   }

   mixin template UsePool(T, uint size = 100) {
     new(uint s) {
       return Pool!(T, size).alloc();
     }
     delete(void* p) {
       Pool!(T, size).free(p);
     }
   }

   class Test {
     mixin UsePool!(Test, 50);
   }

then later in you code, you can just instantiate Test like any 
other object:

   auto t = new Test();

But if instances of Test are often created/released the 
performance is much better. Or you can wired it up so that you 
can pass custom Pools (overriding a default):

   auto t = new(CustomPool) Test();
Mar 21 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 21.03.2012 21:14, F i L wrote:
 And for my third favorite (in no order), I like custom
 allocators/deallocators. They're nice for creating "invisible" memory
 pools:

Sorry to spoil the excitement, but aren't they deprecated? [snip] -- Dmitry Olshansky
Mar 21 2012
parent "Nick Sabalausky" <a a.a> writes:
"F i L" <witte2008 gmail.com> wrote in message 
news:fnlcdpyemasuaomabxxl forum.dlang.org...
 On Wednesday, 21 March 2012 at 17:16:55 UTC, Dmitry Olshansky wrote:
 On 21.03.2012 21:14, F i L wrote:
 And for my third favorite (in no order), I like custom
 allocators/deallocators. They're nice for creating "invisible" memory
 pools:

Sorry to spoil the excitement, but aren't they deprecated? [snip]

Come on, really? What's the reason for this? I did here about delete being depreciated, though I guess I didn't make the connection. Why is delete being removed anyways? I really liked this ability, and I hope that it doesn't completely disappear, even if it's only sugar.

There's a new custom allocator system being worked on. And there's already emplace, which (I imagine) is a key component of it.
Mar 21 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/21/12 12:14 PM, F i L wrote:
 And for my third favorite (in no order), I like custom
 allocators/deallocators.

They don't exist anymore. Andrei
Mar 21 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 21/03/2012 19:32, Andrei Alexandrescu a écrit :
 On 3/21/12 12:14 PM, F i L wrote:
 And for my third favorite (in no order), I like custom
 allocators/deallocators.

They don't exist anymore. Andrei

And we are waiting for the replacement !
Mar 21 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
On Wednesday, 21 March 2012 at 17:16:55 UTC, Dmitry Olshansky 
wrote:
 On 21.03.2012 21:14, F i L wrote:
 And for my third favorite (in no order), I like custom
 allocators/deallocators. They're nice for creating "invisible" 
 memory
 pools:

Sorry to spoil the excitement, but aren't they deprecated? [snip]

Come on, really? What's the reason for this? I did here about delete being depreciated, though I guess I didn't make the connection. Why is delete being removed anyways? I really liked this ability, and I hope that it doesn't completely disappear, even if it's only sugar.
Mar 21 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/20/12 2:02 PM, Andrei Alexandrescu wrote:
 I plan to give a talk at Lang.NEXT
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the
 subject above. There are a few features of D that turned out to be
 successful, in spite of them being seemingly unimportant or diverging
 from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

It's official: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Successful-Features-of-D Andrei
Mar 21 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/21/12, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 It's official:
 http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Successful-Features-of-D

"Go In Three Easy Pieces" followed by "Three Unlikely Successful Features of D". Conspiracy? :P
Mar 21 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/20/12, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 What are your faves? I have a few in mind, but wouldn't want to
 influence answers.

Hey here's a big one: Phobos. Or maybe both Phobos and D2. I don't have the numbers but I think quite a few people thought D was going to die because of a backwards-incompatible change of a language, and the fact that Tango was missing from D2 (it seems people avoided using Phobos in D1 days).
Mar 21 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Wednesday, 21 March 2012 at 17:20:28 UTC, Walter Bright wrote:
 On 3/21/2012 7:23 AM, Adam D. Ruppe wrote:
 But, is import unlikely success, or is this just a
 leftover feeling from my massive bias in the early
 days? I have to say it is my bias, since everyone
 else uses import and they all know it is good.

I knew import would be good :-) It's because I've used languages before with an import, and as a compiler guy, I knew what a kludge #include is. The preprocessor in C/C++ is a crutch to make up for deficiencies in the language.

On the topic of import, mixin imports are something that I believe will eventually become a great deal more popular than they are today. First, there's the advantage of being able to use a language/syntax more appropriate for the task at hand. For example, for things that output html you could just import mixin a raw html file. But the real advantage is that you can still do compile-time processing on this. Plug in an xml parser, or something like pegged, and you can now extend Html and generate D code for it. For example, if you have something like runat="server" on an element, just like in ASP.net you could create a serverside element for this and manipulate it. Because you know exactly which parts are static and which are dynamic, you could (at compile time) create buffers containing the static portions to prevent having to copy things many times. Unlike other languages, there would be no performance hit to doing this because it's all done at compile time. This is just one example. Another one would be automatically creating bindings for a scripting language, or even automatically creating bindings for a C header file.
Mar 21 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, March 21, 2012 22:18:16 Jacob Carlborg wrote:
 On 2012-03-21 20:49, Sean Kelly wrote:
 Druntime actually did use MurmurHash for a while and then dropped it
 because the site had no copyright license for the code (a mistake that
 has since been rectified). I'd consider switching back, though I don't
 really like that MurmurHash has a number of separate implementations
 targeted at different platforms, each having different performance
 characteristics. It's 4x faster than SuperFastHash on x86 but 10x slower
 than SuperFastHash on SPARC, for example.

Would it be possible to use different algorithms on different platforms?

I'm sure that it would be, but it sounds like part of his complaint is that you end up with different implementations per platform with using MurmurHash, and using a different hash algorithm per architecture is just as bad in that respect. If you're trying to absolutely maximize performance though, that would probably be the way to go if there isn't one which is a clear winner on all architectures. It doesn't matter all that much for dmd at present though, since it's x86-only. - Jonathan M Davis
Mar 21 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Kapps wrote:
 or even automatically creating bindings for a C header file.

I've thought about that before. It would be great to have fully automatic linking to C libs. You could even have a cache system that stores .di files and only regenerates them if the .h file was modified.
Mar 21 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Mar 21, 2012, at 1:24 PM, Nick Sabalausky wrote:

 "Sean Kelly" <sean invisibleduck.org> wrote in message=20
 news:mailman.981.1332359368.4860.digitalmars-d puremagic.com...
=20
 Druntime actually did use MurmurHash for a while and
 then dropped it because the site had no copyright license
 for the code (a mistake that has since been rectified).  I'd
 consider switching back, though I don't really like that
 MurmurHash has a number of separate implementations
 targeted at different platforms, each having different
 performance characteristics.  It's 4x faster than SuperFastHash
 on x86 but 10x slower than SuperFastHash on SPARC,
 for example.=3D

People still use SPARC? =20 /me out of the loop

Yup. Though these days it seems more common to use x86 Solaris instead, = and even that subset is transitioning to Linux.=
Mar 21 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
On Wednesday, 21 March 2012 at 21:38:16 UTC, Nick Sabalausky 
wrote:
 "F i L" <witte2008 gmail.com> wrote in message
 news:sofbqiiyvragxjaxqbix forum.dlang.org...
 Kapps wrote:
 or even automatically creating bindings for a C header file.

I've thought about that before. It would be great to have fully automatic linking to C libs. You could even have a cache system that stores .di files and only regenerates them if the .h file was modified.

That hits on the one irritating limitation of CTFE: No I/O. So that cache system would be a no-go right now.

Didn't realize that. Well until IO in CTFE is possible, converting a .h file into a .di file is still possible. Once that's done then it could just be wrapped up into a mixin cache system. D already has a tool to do this I believe (htod). Never used it though.
Mar 21 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Jacob Carlborg wrote:
 But I was thinking more of modifying the compiler and adding a 
 new pragma that calls into my library.

That would probably be a better option I think. In fact, eventually DMD could just have the cache system built in and the ability to import .h files just like .d ones. Now that would be pretty cool. All the .di cache files could be stored in ~/.dmd/ (or equivalent) or converted manually (dmd -CtoD file.h) for distribution.
Mar 21 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 21 March 2012 at 21:01:10 UTC, Kapps wrote:
 On the topic of import, mixin imports are something that I 
 believe will eventually become a great deal more popular than 
 they are today.

I use a *lot* of import() (one of my work projects imports() about 140 files!) but I fairly rarely use mixin with it. What I love about it is simply having a one-piece executable. All your default data is right there. Deployment is easy. If replacement files exist at runtime, you might use them, but if not, you always have a default built in! It is much easier than external resource files, and being able to process is a nice win.
Mar 21 2012
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
 On Wednesday, 21 March 2012 at 21:01:10 UTC, Kapps wrote:
 On the topic of import, mixin imports are something that I 
 believe will eventually become a great deal more popular than 
 they are today.


Definitely.... mixin imports and ctfe gets my 3 votes!
Mar 21 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 21 March 2012 at 19:11:08 UTC, Nick Sabalausky 
wrote:
 Although, while it wasn't a major selling point in and of 
 itself, the ability to put underscores in numeric literals

Aye, that's a nice touch.
 Heh, really?

Oh yes, I was a staunch defender of C++ for a while. "garbage collection? gah apparently you don't know how to use RAII" "header files? more like good thing, it's called a clean interface" BTW one thing I do kinda like is how you can group member functions however you want in C++. For example, in the dmd source, you have special features in separate files, with all the functions still virtual from the header. void InvariantDeclaration::toJsonBuffer(OutBuffer *buf) { } void DtorDeclaration::toJsonBuffer(OutBuffer *buf) { } void StaticCtorDeclaration::toJsonBuffer(OutBuffer *buf) { } etc. That's actually pretty cool. I like that kind of organization. But, eh, D pwns C++ in so many ways that while I still like C++, I'm no longer in the camp of "c++ is obviously great and totally sufficient and if you don't see it, you must be some kind of idiot" like I was for a while.
Mar 21 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 22 March 2012 at 04:49:24 UTC, Nick Sabalausky wrote:
 And then later on someone made sort of a mini file-system where 
 you could add data to a ROM
 image and then query/access it from your code

Now, this reminds me, what if you want to access the compile time files from runtime? For instance, one of my projects lets you include other files in the html. (Something I actually don't like, but it is an easy crutch.) You can also replace these at runtime, so the other team members can change stuff without access to the compiler. Here's what I ended up writing: // filesystem alternatives... string getFile(string name)() { if(std.file.exists(dir ~ name)) return std.file.readText(dir ~ name); else return import(name); } // runtime fetching string getIncludeFile(string name) { enum manifest = ["file1.html", "file2.html", ......]; string manifests() { string cases; foreach(f; manifest) cases ~= "case \""~f~"\": return getFile!(\""~f~"\");"; return cases; } switch(name) { default: assert(0, name); mixin(manifests()); } } I'm a bit disappointed that I needed a list of files duplicated there. With import(), if it is in the import directory, it just works, but then the name must be known at compile time. This is the best I have so far... and i like it, but it isn't quite ideal yet.
Mar 22 2012
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Wednesday, 21 March 2012 at 19:11:08 UTC, Nick Sabalausky 
wrote:

 Although, while it wasn't a major selling point in and of 
 itself, the
 ability to put underscores in numeric literals *really* helped 
 tell me, "Now
 *this* is a language that's very well thought out and values 
 pragmatism."
 And *that* was the other main thing about D that grabbed me.

I take that feature for granted! Try using it in other languages and am always taken back on what it is complaining about, its just a stupid integer literal... oh.
Mar 22 2012
prev sibling next sibling parent "Matt Peterson" <ricochet1k gmail.com> writes:
On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu 
wrote:
 I plan to give a talk at Lang.NEXT 
 (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with 
 the subject above. There are a few features of D that turned 
 out to be successful, in spite of them being seemingly 
 unimportant or diverging from related consecrated approaches.

 What are your faves? I have a few in mind, but wouldn't want to 
 influence answers.


 Thanks,

 Andrei

It isn't mainline yet, but UFCS from git has made working with std.algorithm much nicer. Instead of something like array(filter!"a > 0"(map!((a){return somefunc(a);})(data))) where you can quickly drown in parenthesis and the order seems somewhat backwards, you can use data.map!((a){return somefunc(a);}).filter!"a > 0".array
Mar 22 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Matt Peterson:

 It isn't mainline yet, but UFCS from git has made working with 
 std.algorithm much nicer. Instead of something like 
 array(filter!"a > 0"(map!((a){return somefunc(a);})(data))) 
 where you can quickly drown in parenthesis and the order seems 
 somewhat backwards, you can use data.map!((a){return 
 somefunc(a);}).filter!"a > 0".array

I suggest to compile all your D2 code with -wi (or -w) and -property. And one bug of UFCS will be probably fixed by Hara (http://d.puremagic.com/issues/show_bug.cgi?id=7722 ), so map and filter will require an ending () (I have closed my http://d.puremagic.com/issues/show_bug.cgi?id=7723 ). So your last line is better written like this: data.map!somefunc().filter!q{a > 0}().array() This is indeed a significant improvement in D syntax for functional-style code, because this reduced nesting a lot, making such code significantly more readable. Bye, bearophile
Mar 22 2012
prev sibling parent "Matt Peterson" <ricochet1k gmail.com> writes:
On Friday, 23 March 2012 at 04:07:53 UTC, bearophile wrote:
 I suggest to compile all your D2 code with -wi (or -w) and 
 -property.

Already using -w, and I thought I was using -property. I am now, thanks.
 And one bug of UFCS will be probably fixed by Hara 
 (http://d.puremagic.com/issues/show_bug.cgi?id=7722 ), so map 
 and filter will require an ending () (I have closed my 
 http://d.puremagic.com/issues/show_bug.cgi?id=7723 ).

 So your last line is better written like this:

 data.map!somefunc().filter!q{a > 0}().array()

Yes, I agree. I had to work around a bug a few months ago that using map!some_nested_func wouldn't compile, and I still haven't gotten out of the habit of using delegate literals for all but the simplest maps.
Mar 23 2012