On Wed, Mar 27, 2013 at 12:52:25PM -0400, Nick Sabalausky wrote: > On Wed, 27 Mar 2013 16:34:19 +0100 > "Vidar Wahlberg" <vidar.wahlb...@gmail.com> wrote: [...] > > - While the "auto"-keyword often is great, it can lead to > > difficulties, especially when used as the return type of a > > function, such as "auto foo() { return bar; }". Sometimes you may > > wish to store the result of a function/method call as a global > > variable/class member, but when the function/method returns > > "auto" it's not apparent what the data type may be. While you may > > be able to find out what "bar" is by digging in the source code, > > Here's the trick I like to use: > > // Some var with unknown type > auto var = ...; > pragma(msg, "var: " ~ typeof(var).stringof); > > That will print something like this at compile-time: > > var: int > > Unfortunately (or fortunately, depending on your point of view), it > ignores all convenience aliases and will always give you the *full* > original concrete static type, instead of any prettied-up aliases for > it, but it does work and gets the job done.
What's wrong with using typeof? auto var = ...; typeof(var) anotherVar; ... anotherVar = var; [...] > > - When casting a value to an enum, there's no checking that the > > value actually is a valid enum value. Don't think I ever found a > > solution on how to check whether the value after casting is a > > valid enum value, it hasn't been a pressing issue. > > > > Honestly, I hate that, too. The problem is that enum is (unfortunately) > intended to do double-duty as a bitfield so you can do something like > this: > > enum Options > { > FeatureA = 0b0000_0001; > FeatureB = 0b0000_0010; > FeatureC = 0b0000_0100; > FeatureD = 0b0000_1000; > // etc... > } > > // Use features A and C > auto myOptions = Options.FeatureA | Options.FeatureC; > > That possibility means that D *can't* check for validity as you suggest. As a compromise for now, I'd just use std.conv.to for when I want enum values checked. In any case, using casts should be avoided in D unless there's no other way around it. Casting is a @system-level operation, and most application code shouldn't be using it. > I'm convinced that scenario *should* be considered an entirely separate > thing because cramming it together with regular enumerations creates > conflicting goals with the two usages of "enum", and forces unfortunate > design compromises with both. [...] Yeah, I find using enums for bitfields a bit ugly. I mean, I love using bitfields too (don't know if this is because of my C/C++ background tending toward premature optimization) but conflating them with enums that supposedly should have unique values is IMO a language smell. (And don't get me started on enums being manifest constants instead of "real" enums... I still find that jarring.) T -- Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.