need clarification: will typedef, C struct initialization, etc.

[Adam Ruppe]

On 6/3/10, bearophile <bearophileHUGS at lycos.com> wrote:
> I have seen some situations where library solutions are not good enough yet:
> - std.bitmanip.bitfields is a marvel of programming, but it's trash any way:
> its code can't be maintained, modified, read. It's past the limit of
> decency.

When it comes to code accessibility, the compiler is a black box. You
can't edit it, even in theory, without breaking the language. A
library's source might be ugly, but it is at least available for you
to play with while still writing valid D code.

> And its syntax is not as good as C bitfields.

It is very close though.

> - The best library "typedef" shown so far can't be used two times in the
> same line,

Note: you can use it twice on one line under some circumstances still.

But, be honest, have you ever actually put two typedefs on one line?
If the limitation wasn't explained in the code, would you have ever
noticed this?

The only place where I can see it being an issue is if you use it
inside a larger string mixin. The line numbers get really weird at
times with them. But, it still seems like an academic problem.

> it uses a line of code and file name as workaround, for me this
> is a hack.

When I saw the line/file arguments there, I assumed they were for
debugging purposes - you can use them to make prettier error messages
for the user.

The benefit of letting the distinct types work is a cool side effect.
I'll agree that it is a bit weird, but it does the job and isn't
really evil.

> I have suggested a gensym() to improve the situation a bit, but
> even with it the syntax is not that good and it can produce some template
> bloat.

I think a gensym would be useful. If CTFE could get to a static
variable, that'd be cool.

string getsym() {
      static int count = 0;
      count++;
      return "_AUTOMATICALLY_GENERATED_SYMBOL_" ~ to!string(count);
}

Then, mixin(getsym()) on the useage end. This doesn't work right now
because the global isn't accessible at compile time....

> - The TightArray so far is not good enough for its purposes. Probably it can
> be improved.

Yes.

> - The suggested replacecement for scope seems to have a bit better semantics
> (it's an expression and maybe it doesn't suffer some of the implementation
> bugs of "scope" (see my bug report 4214)), but its syntax is borderline
> awful, so for now it is not an improvement over the current (buggy)
> situation.

The syntax should be easy to turn into:
Scoped!Object obj;

since it is basically just a wrapper struct.

What I especially like about this situation is how it has potential to
do a variety of things, like stack allocation, or malloc(), or just
about anything else. I'd like to see the built in new moved to the
library too, actually.

auto a = new!Object(args...);

should be possible even now!


> - All the proposed library implementations of array comprehensions that I
> have seen are bad (including the one I have used).

I haven't used any so I can't say.