Re: typedef deprecated - now what ?

2011-12-30 Thread Torarin
2011/12/30 Stephan s...@extrawurst.org:
 On 30.12.2011 12:09, Trass3r wrote:

 is there a template or something in phobos to get the same typesafe
 behaviour of good old typedef ?


 I've brought this up several times.
 People just don't give a shit.

 http://d.puremagic.com/issues/show_bug.cgi?id=5467


 thats too bad. pull request looks good. i voted for the ticket, but i guess
 that no one gives shit about that either :(

Sure they give a shit. :-) I think Andrei is currently looking into
ProxyOf for a new reference-counting type constructor.

Torarin


Re: null Vs [] return arrays

2011-04-01 Thread Torarin
2011/4/1 Regan Heath re...@netmail.co.nz:
 On Mon, 28 Mar 2011 17:54:29 +0100, bearophile bearophileh...@lycps.com
 wrote:

 Steven Schveighoffer:

 So essentially, you are getting the same thing, but using [] is slower.

 It seems I was right then, thank you and Kagamin for the answers.

 This may be slightly OT but I just wanted to raise the point that
 conceptually it's nice to be able to express (exists but is empty) and (does
 not exist).  Pointers/references have null as a (does not exist) value and
 this is incredibly useful.  Try doing the same thing with 'int' .. it
 requires you either use int* or pass an additional boolean to indicate
 existence.. yuck.

 I'd suggest if someone types '[]' they mean (exists but is empty) and if
 they type 'null' they mean (does not exist) and they may be relying on the
 .ptr value to differentiate these cases, which is useful.  If you're not
 interested in the difference, and you need performance, you simply use
 'null'.  Everybody is happy. :)

 R


For associative arrays it certainly would be nice to be able to do
something like
string[string] options = [:];
so that functions can manipulate an empty aa without using ref.

Torarin


Re: higher-order funcs for ranges (with usual interface)

2011-02-07 Thread Torarin
If you want to use an interface as a concept, you can take kenji's
adaptTo module and add this:

template conformsTo(T, Interfaces...)
{
 enum conformsTo = AdaptTo!Interfaces.hasRequiredMethods!T;
}

and use it like this

void draw(T)(T shape) if (conformsTo!(T, Shape, Drawable))

This will of course only work for methods, not properties or aliases,
so you still need constraints in some cases.

Torarin