Why not move cast to the standard library?

[Don]

Adam D. Ruppe wrote:
> On Fri, Sep 25, 2009 at 09:29:21AM +0200, Don wrote:
>> I demonstrated that the combination of CTFE + string mixins, 
>> even in D1, was dramatically more powerful than the proposed macros. It 
>> became clear that we didn't have a macro design that was anywhere near 
>> powerful enough, and macros were postponed to D3. We don't know how they 
>> should work.
>> By all means make a proposal.
> 
> I was thinking of a simple one for D2 a while back, but canceled my post
> since it is basically just sugar for what it does now. But, on the other
> hand, that is a bit simpler to implement, so let me throw it out.
> 
> I propose that a macro (in D2; I don't know about a more elegant D3 design)
> is merely a CTFE function that is mixed in, and takes symbols as strings.
> 
> Let me give an example:
> 
> ====
> macro max(int a, int b) {
> 	return a ~ " > " ~ b ~ " ? " ~ a ~ " : " ~ b;
> }
> 
> void main() {
> 	auto num1 = 10;
> 	auto num2 = 20;
> 
> 	auto result = max(num1, num2);
> }
> ====
> 
> This would be the same as:
> 
> ====
> string max(string a, string b) {
> 	return a ~ " > " ~ b ~ " ? " ~ a ~ " : " ~ b;
> }
> 
> void main() {
> 	auto num1 = 10;
> 	auto num2 = 20;
> 
> 	auto result = mixin(max("num1", "num2"));
> }
> 
> ===============
> 
> So:
> 	a) A macro function always returns a string, which is mixed in at the
> 	   point where you used it
> 
> 	b) Its arguments are actually strings. (I don't know if I'm happy with
> 	   what I did in the above example, using int when they are actually
> 	   string, but having some type checking seems more sane than actually
> 	   going all string. All string feels too C preprocessor like.)
> 
> 	c) All the arguments are the name of the variable as a string. It
> 	   basically just tosses quotes around whatever you literally wrote
> 	   on the line when you used it. (So passing a string literal would
> 	   actually send "\"what you wrote\"" to the macro.)
> 
> 
> This doesn't do anything we can't already do with the language, but I think
> it looks a little prettier, which might make the functions a bit easier for
> the user. Though it would still be the same for the lib writer, of course.

I agree, for a user that'd give you all the syntax sugar you'd hope for 
from a macro. You haven't said what happens with arguments which are 
expressions rather than symbols, though, and that's the interesting bit. 
I'd propose it just does a .stringof on them. Basically the same as what 
my BLADE library did manually.
It'd actually be interesting to see how much ugliness is left after 
doing that. Further refinement of macro proposals might be aimed at 
removing whatever hackiness is left.