static parameters

[Jason House]

Bill Baxter wrote:
> On page 30 of WalterAndrei.pdf it talks about static function parameters.
> 
> It says
>    void foo(static int i, int j) { ... }
> will become a synonym for the template
>    void foo(int i)(int j) { ... }
> 
> And the reason given is it's supposed to make templates "easier for 
> mortals".
> 
> I don't really see how that makes anything easier.  It's longer to type 
> first of all.  And you still have to be aware of the compile-time / 
> runtime distinction, this just makes it a little harder to see.  And it 
> introduces issues like what to do if there are both template parameters 
> and static arguments, and what to do with __traits for such functions, 
> and what the parameters tuple should look like, and whether you can have 
> foo(int i, static j), and whether you can still call it as foo!(7)(5), 
> and if you can call foo(int i)(int j) as foo(3,x)?
> 
> And if it is just like a template can you take &foo?  If not, how do you 
> take the address of a particular specialization of the function?  Do you 
> revert back to foo!(3) then?


Those are all good points!


> In short it seems like a classic case of a feature that adds little 
> benefit, but a fair number of new rules that everyone will have to 
> remember, and in the end it could very likely stomp on the toes of some 
> other future features that would be much more useful.


I think this style of functionality could be useful.  Provided that I 
don't have to write lots of function definitions, having the compiler 
figure out what is or isn't compile-time values and optimizing based on 
that is a good thing.  Personally, I think something like the return 
keyword could be helpful here too


> 
> As far as I can tell, this is just another way to do something we can 
> already do, and all we gain from it is the ability to save two 
> characters on the calling side for functions that are only templated on 
> const values.
> 
> --bb