Re: Three Unlikely Successful Features of D
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
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
Adam D. Ruppe destructiona...@gmail.com 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
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
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
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
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
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
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
H. S. Teoh hst...@quickfur.ath.cx 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 of code. I saw this trick in someone else's code once,
loved
Re: Three Unlikely Successful Features of D
It's probably far too early to think about this with all the other important issues you're addressing but have you given much thought to improving the hashing function? I haven't hit any issues with the speed of the current hasher but better performance is always welcome. MurmurHash seems to be all the rage these days with a lot of languages and systems adopting it http://en.wikipedia.org/wiki/MurmurHash (it compiles down to ~52 instructions on x86). It'd be interesting to see benchmarks with it. I'm not sure where the current hashing function lives to see what it's like. Regards, Brad Anderson More throughput but higher latency. http://codepad.org/kCVQ8eoq Murmurhash was a little slower than CityHash but both are a little expensive for very few bytes.
Re: Three Unlikely Successful Features of D
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
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
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
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
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
On Tue, 20 Mar 2012 15:02:15 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I plan to give a talk at Lang.NEXT (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the subject above. There are a few features of D that turned out to be successful, in spite of them being seemingly unimportant or diverging from related consecrated approaches. What are your faves? I have a few in mind, but wouldn't want to influence answers. The two that I would cite are auto and slice syntax. I see others have chimed in with the same two. These were two features that did *not* attract me to D, but I found them to be two of my favorites, and ones I miss the most when writing in other languages. If I had to pick a third, I'd say the omitting parentheses for 1-arg templates was something I didn't expect to be as great as it is. Possibly one other thing I didn't expect to be so nice was shared (more specifically, the implications when something is *not* shared). That enabled weak-pure functions which I think are going to be a HUGE feature for D. -Steve
Re: Three Unlikely Successful Features of D
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
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
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
On Wed, Mar 21, 2012 at 2:06 AM, Martin Nowak d...@dawgfoto.de wrote: It's probably far too early to think about this with all the other important issues you're addressing but have you given much thought to improving the hashing function? I haven't hit any issues with the speed of the current hasher but better performance is always welcome. MurmurHash seems to be all the rage these days with a lot of languages and systems adopting it http://en.wikipedia.org/wiki/**MurmurHashhttp://en.wikipedia.org/wiki/MurmurHash (it compiles down to ~52 instructions on x86). It'd be interesting to see benchmarks with it. I'm not sure where the current hashing function lives to see what it's like. Regards, Brad Anderson More throughput but higher latency. http://codepad.org/kCVQ8eoq Murmurhash was a little slower than CityHash but both are a little expensive for very few bytes. Interesting. Thanks for the link. Regards, Brad Anderson
Re: Three Unlikely Successful Features of D
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
On Tue, Mar 20, 2012 at 11:54:37PM -0600, Brad Anderson wrote: [...] It's probably far too early to think about this with all the other important issues you're addressing but have you given much thought to improving the hashing function? I haven't hit any issues with the speed of the current hasher but better performance is always welcome. MurmurHash seems to be all the rage these days with a lot of languages and systems adopting it http://en.wikipedia.org/wiki/MurmurHash (it compiles down to ~52 instructions on x86). It'd be interesting to see benchmarks with it. I'm not sure where the current hashing function lives to see what it's like. [...] The current implementation actually has (at least) two different hash functions: - Paul Hsieh's SuperFastHash (rt.util.hash.hashOf) - A custom hash for char[] and string: look in rt/typeinfo/ti_Ag.d for class TypeInfo_Aa, which has this: hash_t hash = 0; foreach (char c; s) hash = hash * 11 + c; I'm going to benchmark both hash functions to see which is actually faster. I suspect the custom hash is faster for small strings, though it may not have good hash distribution. T -- Microsoft is to operating systems security ... what McDonalds is to gourmet cooking.
Re: Three Unlikely Successful Features of D
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
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
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
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
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
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
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
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
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
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
On 3/21/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: It's official: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Successful-Features-of-D Go In Three Easy Pieces followed by Three Unlikely Successful Features of D. Conspiracy? :P
Re: Three Unlikely Successful Features of D
Adam D. Ruppe destructiona...@gmail.com 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
F i L witte2...@gmail.com 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
On 3/20/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are your faves? I have a few in mind, but wouldn't want to influence answers. Hey here's a big one: Phobos. Or maybe both Phobos and D2. I don't have the numbers but I think quite a few people thought D was going to die because of a backwards-incompatible change of a language, and the fact that Tango was missing from D2 (it seems people avoided using Phobos in D1 days).
Re: Three Unlikely Successful Features of D
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 http://en.wikipedia.org/wiki/MurmurHash (it compiles down to ~52 instructions on x86). It'd be interesting to see benchmarks with it. I'm not sure where the current hashing function lives to see what it's like. Druntime actually did use MurmurHash for a while and then dropped it because the site had no copyright license for the code (a mistake that has since been rectified). I'd consider switching back, though I don't really like that MurmurHash has a number of separate implementations targeted at different platforms, each having different performance characteristics. It's 4x faster than SuperFastHash on x86 but 10x slower than SuperFastHash on SPARC, for example.
Re: Three Unlikely Successful Features of D
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 s...@invisibleduck.org 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
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
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
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
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
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
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
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
On Mar 21, 2012, at 1:24 PM, Nick Sabalausky wrote: Sean Kelly s...@invisibleduck.org 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
Kapps opantm2+s...@gmail.com 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
F i L witte2...@gmail.com 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
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
On Wednesday, 21 March 2012 at 21:38:16 UTC, Nick Sabalausky wrote: F i L witte2...@gmail.com 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
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
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
On 03/21/2012 10:37 PM, Nick Sabalausky wrote: F i Lwitte2...@gmail.com 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
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
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
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
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
Adam D. Ruppe destructiona...@gmail.com 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 destructiona...@gmail.com 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)? ;)
Three Unlikely Successful Features of D
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
Re: Three Unlikely Successful Features of D
I really like the $ opperator on slices. It's something small and looks rather unneeded. When I was dealing with java I never even wished it was there but when I came to d and did some array manipulation I was really glad we had that $ sign. I regularly use it and I don't seem to be the only one feeling that way. Maarten
Re: Three Unlikely Successful Features of D
On 20-03-2012 20:02, Andrei Alexandrescu wrote: I plan to give a talk at Lang.NEXT (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the subject above. There are a few features of D that turned out to be successful, in spite of them being seemingly unimportant or diverging from related consecrated approaches. What are your faves? I have a few in mind, but wouldn't want to influence answers. Thanks, Andrei In no particular order: Lazy values, guaranteed initialization, scope guards, perhaps array slices, alias this / single inheritance, unittest blocks. -- - Alex
Re: Three Unlikely Successful Features of D
On 20.03.2012 23:02, Andrei Alexandrescu wrote: I plan to give a talk at Lang.NEXT (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the subject above. There are a few features of D that turned out to be successful, in spite of them being seemingly unimportant or diverging from related consecrated approaches. What are your faves? I have a few in mind, but wouldn't want to influence answers. To throw in a few: Scope guards, opDispatch, alias and _string_ template parameters. -- Dmitry Olshansky
Re: Three Unlikely Successful Features of D
On Tue, Mar 20, 2012 at 02:02:15PM -0500, Andrei Alexandrescu wrote: I plan to give a talk at Lang.NEXT (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the subject above. There are a few features of D that turned out to be successful, in spite of them being seemingly unimportant or diverging from related consecrated approaches. What are your faves? I have a few in mind, but wouldn't want to influence answers. [...] By far: CTFE. Unittest blocks, extended concept of purity, template syntax (as opposed to C++'s ugly mess), all types have a default value (.init - makes it so painless to write generic code!), scope guards. T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Re: Three Unlikely Successful Features of D
On 20.03.2012 20:02, Andrei Alexandrescu wrote: I plan to give a talk at Lang.NEXT (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the subject above. There are a few features of D that turned out to be successful, in spite of them being seemingly unimportant or diverging from related consecrated approaches. What are your faves? I have a few in mind, but wouldn't want to influence answers. Thanks, Andrei There's one huge one. Strings as built-in types, including concatenation and slicing. This meant that they could be constant-folded. Together with 'static if', this was the basis of metaprogramming in D. Pretty much all the rest was a natural consequence of that foundation. It was *completely* unexpected. When, as a D newbie, I posted some of my initial exploration of the language, Walter wrote I had no idea this was even possible. Probably not what you have in mind, though -- it *was* expected to be a success, just not to anything like this extent. * pragma(msg) is something that's been used 100X as often as anticipated. * Builtin properties of types, eg int.max. Doesn't sound like much of an improvement over a header file of constants, but it's had a huge impact. It really encourages you to write correct code, (I especially notice it for floating point, but I bet if you grep for int.max in D code, you'll get far more hits than for MAXINT in C code).
Re: Three Unlikely Successful Features of D
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.
Re: Three Unlikely Successful Features of D
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
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
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
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
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
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
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
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
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
On 3/20/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are your faves? I have a few in mind, but wouldn't want to influence answers. Here's one: C compatibility. Maybe it wasn't unlikely to be successful but most new languages don't seem to care about C compatibility all that much. It's been a boon for D though.
Re: Three Unlikely Successful Features of D
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
On 3/20/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Here's one: C compatibility. Now a real one: auto type inference. Could you possibly imagine what the type name should be on the left-hand side? ? x = retro(stride(chain([1, 2], [3, 4]), 2)); Who knows. auto is great for these higher-level types.
Re: Three Unlikely Successful Features of D
On 21 March 2012 11:49, Andrej Mitrovic andrej.mitrov...@gmail.com 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
- 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
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
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
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
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
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
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
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
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
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
Walter Bright newshou...@digitalmars.com wrote in message news:jkb2v6$kq4$2...@digitalmars.com... On 3/20/2012 3:58 PM, Nick Sabalausky wrote: Alias in particular is a much bigger deal than it seems since it's seemingly trivial but can be *incredibly* helpful with templates *and* with importing. I'd have to agree with this. I find it amazing that other languages entirely miss the boat on this. C++ has a very crippled version of it in template template parameters. I particulary love how D's alias is used to disambiguate symbol conflicts. Brilliant approach. I know I wouldn't have thought of it.
Re: Three Unlikely Successful Features of D
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
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
H. S. Teoh hst...@quickfur.ath.cx 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* bad...in certain cases...if there were at
least scope guards).
- Name any
Re: Three Unlikely Successful Features of D
Nick Sabalausky a@a.a wrote in message news:jkbcoh$15k3$1...@digitalmars.com... And even *that* still doesn't work if you don't catch *every* exception (and then rethrow the ones you don't care about? Ick!). And AIUI, even *that* doesn't work in C++ because, IIRC, the class hierarchy doesn't have *any* common root. So what, are you going to have a catch block for *every* class type in your program? Heck, even *that* might be feasable in D thanks to the compile-time reflection and quality metaprogramming, but with C++, you're SOL.
Re: Three Unlikely Successful Features of D
Adam D. Ruppe destructiona...@gmail.com 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
On 3/21/12, H. S. Teoh hst...@quickfur.ath.cx 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
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
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
