On 11/2/2014 5:44 AM, bearophile wrote:
It happens often enough to justify a similar feature in Ada2012. (This is the
main point of this whole discussion. The other parts of this answer are less
important).
Why aren't you using Ada if this is critical to you? (I'm not being sarcastic,
this is a fair question.)
All features have a cost/benefit to them. The costs are never zero. Laying on
more and more features of minor benefit will destroy the language, and even
you won't use it.
I agree. But freezing D design is not a good idea.
I'm not saying "freeze the design". I'm saying that if things are wrapped in
enough bubble wrap, few programmers will want to use the language. After all, I
don't wear a firesuit or helmet when I drive my car.
(Note: so far I don't care
for C++ interoperativity much.
I understand. But poor C++ interop is preventing quite a few people from using
D. Validating printf format strings is not.
You could also write:
formattedwrite!"the format string %s %d"(args ...)
if you like. The fact that nobody has bothered to suggests that it doesn't add
much value over writefln().
Plenty of people have bothered, there's an implementation.
1. I've heard proposals, but no implementation.
2. If it exists, why aren't you using it?
3. It is obviously doable in D. No language extension required. You can even
write one and contribute it!
More annotations => more annoyance for programmers. Jonathan Blow
characterizes this as "friction" and he's got a very good point. Programmers
have a limited tolerance for friction, and D must be very careful not to step
over the line into being a "bondage and discipline" language that nobody uses.
The annotation is used only once at the definition point of the flags. So the
"annotation" here is essentially a way to tell the compiler that you don't want
a regular enumeration, but a flags. It's like having two different language
constructs, enums and flags.
I understand that - yet another basic type in the system. I believe you majorly
underestimate the costs of these things, or even assign zero cost to them.
So it's a way to offer the programmer a chance to
express intent and make the code more expressive/readable. And this allows to
make the semantics of enums more strict. It's a win-win-win situation.
Again, you badly underestimate the costs or just pretend they aren't there.
The real
downside is increased language complexity, but as I explained in past, well
designed clean features are not the main source of complexity.
I must ask, have you ever designed a house? Everything is a tradeoff. Want a
bigger closet? What becomes smaller as a result? Do you want a view from the
kitchen window or do you want a convenient door from the kitchen to the garage?
If you give the view to the kitchen, are you willing to give up the view from
the study? Do you accept this change will add $10,000 to the budget? This other
change will require approval from the zoning people, causing delays. How will
the position of the windows make the house look from the street? And on and on.
Language design is the same thing. You can't just "explain" that the solution is
to make "clean" features. Like a house design, every feature in a language
interacts with every other feature.
And formalizing a programmer idiom is often not a bad idea.
Sorry, this is just hand-waving.
It is not suboptimal.
D is at a reasonable optimum point for this.
In my opinion it has some faults. I am not alone with this opinion. So I think
it's not at the optimum.
A reasonable optimum point is not equal to "nobody can find any fault with it".
A reasonable optimum point is where the faults are more acceptable than the
known alternatives.
The implication that this is thoughtlessly thrown together against all reason
is just not correct.
I didn't say D implicit casts are randomly designed :-) I said that they are
currently not very good
I strongly reject that notion.
or the best possible.
It's the best anyone has come up with for now.
I think the size casting that loses bits is still regarded as safe.
It is memory safe.
Probably that's why there are two kind of casts in Haskell.
x & 0xFF
loses bits as well. What do you propose to do about that flaw?
