My thoughts & experiences with D so far, as a novice D coder

[H. S. Teoh]

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.wahlberg at 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.