Re: Three Unlikely Successful Features of D

[Matt Peterson]

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.

Re: Three Unlikely Successful Features of D

[bearophile]

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

Re: Three Unlikely Successful Features of D

[Matt Peterson]

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

Re: Three Unlikely Successful Features of D

[Jesse Phillips]

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.

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"Adam D. Ruppe"  wrote in message 
news:oyqxvngsgjfmrlrwh...@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.

Re: Three Unlikely Successful Features of D

[Adam D. Ruppe]

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.

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"Adam D. Ruppe"  wrote in message 
news:utkgtgcgguydxrabk...@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)?" ;)

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"Adam D. Ruppe"  wrote in message 
news:vuegxcpcbsefvmjdq...@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.

Re: Three Unlikely Successful Features of D

[Adam D. Ruppe]

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.

Re: Three Unlikely Successful Features of D

[Tove]

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!

Re: Three Unlikely Successful Features of D

[Adam D. Ruppe]

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.

Re: Three Unlikely Successful Features of D

[H. S. Teoh]

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...

Re: Three Unlikely Successful Features of D

[Timon Gehr]

On 03/21/2012 10:37 PM, Nick Sabalausky wrote:

"F i L"  wrote in message
news:sofbqiiyvragxjaxq...@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.

Re: Three Unlikely Successful Features of D

[F i L]

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.

Re: Three Unlikely Successful Features of D

[deadalnix]

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 !

Re: Three Unlikely Successful Features of D

[F i L]

On Wednesday, 21 March 2012 at 21:38:16 UTC, Nick Sabalausky 
wrote:

"F i L"  wrote in message
news:sofbqiiyvragxjaxq...@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.

Re: Three Unlikely Successful Features of D

[Jacob Carlborg]

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

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"F i L"  wrote in message 
news:sofbqiiyvragxjaxq...@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.

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"Kapps"  wrote in message 
news:nnqtlpjqwdnzuwiqc...@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.

Re: Three Unlikely Successful Features of D

[Sean Kelly]

On Mar 21, 2012, at 1:24 PM, Nick Sabalausky wrote:

> "Sean Kelly"  wrote in message 
> news:mailman.981.1332359368.4860.digitalmar...@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

Yup.  Though these days it seems more common to use x86 Solaris instead, and 
even that subset is transitioning to Linux.

Re: Three Unlikely Successful Features of D

[F i L]

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.

Re: Three Unlikely Successful Features of D

[Sean Kelly]

On Mar 21, 2012, at 2:18 PM, 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?

Depends whether there's any reason to have different platforms attempt to 
generate the same hash for a given input.

Re: Three Unlikely Successful Features of D

[Jonathan M Davis]

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

Re: Three Unlikely Successful Features of D

[Jacob Carlborg]

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

Re: Three Unlikely Successful Features of D

[Kapps]

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.

Re: Three Unlikely Successful Features of D

[Jacob Carlborg]

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

Re: Three Unlikely Successful Features of D

[Timon Gehr]

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

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"Sean Kelly"  wrote in message 
news:mailman.981.1332359368.4860.digitalmar...@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

Re: Three Unlikely Successful Features of D

[Don]

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?

Re: Three Unlikely Successful Features of D

[Sean Kelly]

On Mar 20, 2012, at 10:54 PM, 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 
>  (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.

Re: Three Unlikely Successful Features of D

[Andrej Mitrovic]

On 3/20/12, Andrei Alexandrescu  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).

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"F i L"  wrote in message 
news:fnlcdpyemasuaomab...@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.

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"Adam D. Ruppe"  wrote in message 
news:fuxnqnmrskrfqqmhd...@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).

Re: Three Unlikely Successful Features of D

[Andrej Mitrovic]

On 3/21/12, Andrei Alexandrescu  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

Re: Three Unlikely Successful Features of D

[Andrei Alexandrescu]

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

Re: Three Unlikely Successful Features of D

[Andrei Alexandrescu]

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

Re: Three Unlikely Successful Features of D

[Andrei Alexandrescu]

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

Re: Three Unlikely Successful Features of D

[F i L]

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.

Re: Three Unlikely Successful Features of D

[Walter Bright]

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.

Re: Three Unlikely Successful Features of D

[Walter Bright]

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.

Re: Three Unlikely Successful Features of D

[Walter Bright]

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.

Re: Three Unlikely Successful Features of D

[Dmitry Olshansky]

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

Re: Three Unlikely Successful Features of D

[Walter Bright]

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".)

Re: Three Unlikely Successful Features of D

[F i L]

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();

Re: Three Unlikely Successful Features of D

[H. S. Teoh]

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  (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.

Re: Three Unlikely Successful Features of D

[F i L]

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.

Re: Three Unlikely Successful Features of D

[Brad Anderson]

On Wed, Mar 21, 2012 at 2:06 AM, Martin Nowak  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 
>> >
>> (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

Re: Three Unlikely Successful Features of D

[Kagamin]

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.

Re: Three Unlikely Successful Features of D

[Don Clugston]

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 {  ... }

Re: Three Unlikely Successful Features of D

[pillsy]

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

Re: Three Unlikely Successful Features of D

[Steven Schveighoffer]

On Tue, 20 Mar 2012 15:02:15 -0400, 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.


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

Re: Three Unlikely Successful Features of D

[Adam D. Ruppe]

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.

Re: Three Unlikely Successful Features of D

[Patrick Down]

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

Re: Three Unlikely Successful Features of D

[Masahiro Nakagawa]

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

Re: Three Unlikely Successful Features of D

[Jan Knepper]

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...

Re: Three Unlikely Successful Features of D

[so]

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.

Re: Three Unlikely Successful Features of D

[Martin Nowak]

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  (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.

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"H. S. Teoh"  wrote in message 
news:mailman.949.1332305140.4860.digitalmar...@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 o

Re: Three Unlikely Successful Features of D

[Jacob Carlborg]

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

Re: Three Unlikely Successful Features of D

[Walter Bright]

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!

Re: Three Unlikely Successful Features of D

[Joshua Niehus]

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)

Re: Three Unlikely Successful Features of D

[Brad Anderson]

On Tue, Mar 20, 2012 at 10:47 PM, H. S. Teoh  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.)
>
>
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  (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

Re: Three Unlikely Successful Features of D

[H. S. Teoh]

On Tue, Mar 20, 2012 at 09:59:27PM -0400, Nick Sabalausky wrote:
> "H. S. Teoh"  wrote in message 
> news:mailman.933.1332286692.4860.digitalmar...@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
> >> 

Re: Three Unlikely Successful Features of D

[Jay Norwood]

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.

Re: Three Unlikely Successful Features of D

[Andrej Mitrovic]

On 3/21/12, Walter Bright  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. :)

Re: Three Unlikely Successful Features of D

[bcs]

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.

Re: Three Unlikely Successful Features of D

[bcs]

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.

Re: Three Unlikely Successful Features of D

[Andrei Alexandrescu]

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

Re: Three Unlikely Successful Features of D

[Walter Bright]

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.

Re: Three Unlikely Successful Features of D

[Andrej Mitrovic]

On 3/21/12, H. S. Teoh  wrote:
> This is actually quite buggy right now... but that's merely an
> implementation issue. :-)  My new AA implementation..

You know it would be sweet if we got map types as well instead of
using void[0][Key] hacks. :)

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"Adam D. Ruppe"  wrote in message 
news:txwnbkafemkurcqje...@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.

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"Nick Sabalausky"  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.

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"H. S. Teoh"  wrote in message 
news:mailman.933.1332286692.4860.digitalmar...@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* b

Re: Three Unlikely Successful Features of D

[Rene Zwanenburg]

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] ~ ");";
}

Re: Three Unlikely Successful Features of D

[Rene Zwanenburg]

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] ~ ");";
}

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

"Walter Bright"  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.

Re: Three Unlikely Successful Features of D

[bearophile]

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

Re: Three Unlikely Successful Features of D

[Adam D. Ruppe]

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);

Re: Three Unlikely Successful Features of D

[Adam D. Ruppe]

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.)

Re: Three Unlikely Successful Features of D

[Geoffrey Biggs]

On Mar 21, 2012, at 6:43 AM, 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).

Python has had slices since at least 2000. I can't imagine using Python without 
them, and I always miss them when using languages such as C++. D providing 
slices in a compiled, system programming language is a massive advantage over 
other such languages.

Geoff

Re: Three Unlikely Successful Features of D

[Walter Bright]

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?

Re: Three Unlikely Successful Features of D

[Brad Roberts]

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

Re: Three Unlikely Successful Features of D

[Walter Bright]

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".

Re: Three Unlikely Successful Features of D

[H. S. Teoh]

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.

Re: Three Unlikely Successful Features of D

[Jonathan M Davis]

On Tuesday, March 20, 2012 14:02:15 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.

I'd probably list

1. auto
2. static if
3. template constraints

But slices is also a good one. Thread-local by default is also one that could 
be listed, but I'm not sure that that's really "unlikely." Its benefits are 
quite obvious with little explanation. The only question is how well it works 
when trying to actually share data and communicate between threads, which is 
an area where we still need work (e.g. finishing implementing shared).

- Jonathan M Davis

Re: Three Unlikely Successful Features of D

[Nick Sabalausky]

- 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.

Re: Three Unlikely Successful Features of D

[James Miller]

On 21 March 2012 11:49, Andrej Mitrovic  wrote:
> 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.

Also when dealing with complex parameterized types, so when I have a
function that gives me the type

foo!(bar!(int, 5), baz!string) I don't have to know that, I can just
use `auto` instead.

--
James Miller

Re: Three Unlikely Successful Features of D

[Andrej Mitrovic]

On 3/20/12, Andrej Mitrovic  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.

Re: Three Unlikely Successful Features of D

[David]

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!

Re: Three Unlikely Successful Features of D

[Andrej Mitrovic]

On 3/20/12, Andrei Alexandrescu  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.

Re: Three Unlikely Successful Features of D

[Piotr Szturmaj]

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.

Re: Three Unlikely Successful Features of D

[deadalnix]

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.

Re: Three Unlikely Successful Features of D

[F i L]

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.

Re: Three Unlikely Successful Features of D

[Andrei Alexandrescu]

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

Re: Three Unlikely Successful Features of D

[Sean Kelly]

On Mar 20, 2012, at 12: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.

strings as a built-in type, plus slicing.  There's a lot of great stuff in D, 
but that one's a game changer.

Re: Three Unlikely Successful Features of D

[Walter Bright]

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).

Re: Three Unlikely Successful Features of D

[dsimcha]

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.

Re: Three Unlikely Successful Features of D

[H. S. Teoh]

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

Re: Three Unlikely Successful Features of D

[Don]

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.

Re: Three Unlikely Successful Features of D

[Jesse Phillips]

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.