grauzone wrote:
Andrei Alexandrescu wrote:
3. It was mentioned in this group that if getopt() does not work in
SafeD, then SafeD may as well pack and go home. I agree. We need to
make it work. Three ideas discussed with Walter:
If that's such an issue, why don't you just change it and use a struct
defined by the user? structs are natural name-value pairs that work at
compile time, and they can always be returned from functions.
4. Allow private members inside a template using the eponymous trick:
template wyda(int x) {
private enum geeba = x / 2;
alias geeba wyda;
}
Why is this important?
Apart from this...
Whatever happened to the concurrency stuff? Do you really want users to
deal with the broken and incomplete implementation right now? What about
the issues of constructing immutable data? (Eh, are we supposed to cast
from mutable data, and hope everything goes right?) Right now,
multithreaded programming in D2 is probably even more a pain than in C++.
Also, you should fix the auto-flattening of tuples before it's too late.
I think everyone agrees that auto-flattening is a bad idea, and that
tuples should be nestable. Flattening can be done manually with an unary
operator.
(Introducing sane tuples (e.g. unify type and value tuples, sane and
short syntax, and all that) can wait for later if it must. Introducing
these can be downwards compatible, I hope.)
Non-flattening should be on the list but I am very afraid the solution
would take a long time to design, implement, and debug. I must discuss
this with Walter.
Andrei
