On 07/28/2012 05:55 PM, Jonathan M Davis wrote:
On Saturday, July 28, 2012 17:48:21 Chad J wrote:
I suppose that works, but it isn't very consistent with how type safety
is normally done. Also it's extremely verbose. I'd need a lot of
convincing to chose a language that makes me write stuff like this:
auto foo = someFunc();
static assert(isInteger!(typeof(foo));
instead of:
int foo = someFunc();
I can tolerate this in D because of the obvious difference in power
between D's metaprogramming and other's, but it still seems very
lackluster compared to what we could have.
Why would you even need to check the return type in most cases? It returns
whatever range type returns, and you pass it on to whatever other range-based
function you want to use it on, and if a template constraint fails because the
type wasn't quite right, _then_ you go and figure out what type of range it
returned. But as long as it compiles with the next range-based function, I
don't see why it would matter all that much what the exact return type is.
auto's inferrence is saving you a lot of trouble (especially when it comes to
refactoring). Without it, most range-based stuff would be completely unusable.
- Jonathan M Davis
What's missing then is:
- A compiler-checked and convenient/readable way of documenting what is
being produced by an expression.
- A way to localize errors if a 3rd party breaks their API by changing
the return type of some function I call. "I want to make sure."
- Ease of learning. I would definitely reach for "InputRange r = ..."
before reaching for "auto r = ...; static assert (isInputRange!...);".
I do love auto. I think it's awesome. I'm just trying to explore
what's missing, because there is something bugging me about the current
situation.
I think it's this problem: Reading code that declares a bunch of
variables as "auto" can be disorienting. Sometimes I want to put more
specific types in my declarations instead of "auto". This makes things
much more readable, in some cases. However, this is very difficult to
do now because a bunch of stuff in Phobos returns these voldemort types.
I don't know what to replace the "auto" declarations with to make
things more readable. I'd at least like some way of specifying the
type; a way that is as concise as the expression that yielded the type.
It reminds me of the situation in dynamically-typed languages where
you're /forced/ to omit type information. It's not as bad here because
any eventual mistakes due to type mismatches are still caught at
compile-time in D. However, there still seems to be some amount of
unavoidable guesswork in the current system. There is something
unsettling about this.
