On Sunday 09 January 2011 14:31:11 Sean Eskapp wrote: > >That's.. ehem.. quite limiting. :) (you probably meant heap) > > I meant what I said, and I said what I meant. Stack allocated implicitly > would be fine, but explicit stack allocation, like declaring variables, > doesn't happen in purely functional languages. > > Personally, I like being able to impose this contract on myself to write > functional code, just like I like being able to use const and @safe. > Apparently I'm in the vast minority!
You can declare variables in at least some functional languages. Take Haskell's let for example. Haskell is purely functional and yet you can effectively declare a local variable. You can't mutate it, but it's a local variable. D is not a functional language, nor is it trying to be one. It has added pure and immutable allowing you to better program in a functional manner, primarily with multi-threading in mind. What we have does that and overall does it quite well. Disallowing local variables gives you _no_ benefit whatsoever that I can see, and at least some functional languages effectively allow it anyway. D already has purity, which gives you the ability to program functionally. If you want to be overly-restrictive and not use local variables, that's your perogative, but that has no effect whatsoever on the result of the function, so there's no reason to enforce that a function behave that way even if it were actually desirable for some reason. If something affects the internal behavior of a function but not its result (including how it affects all variables external to it, not just its return value), then there's no reason to enforce that in the function's signature. That's encapsulated in the function, and the caller doesn't care. - Jonathan M Davis
