On Tuesday, 23 September 2014 at 16:01:35 UTC, Andrei
Alexandrescu wrote:
On 9/23/14, 7:43 AM, Don wrote:
On Monday, 22 September 2014 at 14:56:26 UTC, Andrei
Alexandrescu wrote:
On 9/22/14, 2:39 AM, Don wrote:
Yes, but you're advocating a hack.
Oh but I very much disagree.
Now you are scaring me. It worries me that this kind of
"solution" can
be viewed as acceptable. It's the kind of hacky code I left
C++ to
escape from.
Hmm... doesn't strike me as similar to C++-specific hacks, but
I understand the sentiment.
People in this thread said it was "ugly" and you dismissed
that.
Nononononono. I totally agree some may find it ugly! It's
"unusable" I have a problem with.
I think that "unusable" has been used with two meanings in this
thread.
That's why I've been using the word "hack".
But
this isn't just a matter of personal aesthetics.
If you want something objective, it's not DRY, and it's
verbose in a
non-trivial way. The hacky design leads to error-prone code.
eg you can easily get a copy-paste bug because it's not DRY.
alias HMENU = Typedef!(void*, __MODULE__ ~ ".HMENU");
alias HFONT = Typedef!(void*, __MODULE__ ~ ".HMENU"); // oops
mixin(makeTypedef!("HMENU", void*));
mixin(makeTypedef!("HFONT", void*));
I said and I repeat: I do agree it's less convenient than a
baked-in facility. Even with the proper default arguments and
all. But I stand by Typedef as an adequate abstraction.
You need a very, very good reason to require a string mixin in
user code. I'm not seeing that here. The cure is worse than the
disease.
How many libraries did you use that came with no idioms for
their usage?
Describing this as an "idiom" is extremely generous. My
standards are
higher.
Well "extremely generous" is not "deluded" so I'll take that
:o).
And it does seem to me, that because it isn't possible to do
a proper
library typedef, you've attempted to redefine what a Typedef
is supposed
to do. And sure, it you remove the requirement to create a
unique type,
Typedef isn't broken.
You're two paragraphs away from "library Typedefs are
fundamentally
broken". Now which one is it?
Phobos' Typedef is fundamentally broken, and that your claim
that it is
not, relies on moving the goalposts.
I disagree. I'm not one to dismiss good arguments. But there
aren't many here. There's gotta be a point at which you'll
agree the whole argument against Typedef has no legs. It's
working as designed (I forgot who designed it),
the design fits the purpose, the semantics never surprised me,
and when people
now come with the pitchforks that it's broken, all I can do is
send them to the manual. IT WORKS.
The argument is that if you use Typedef for real-world use cases,
your code is broken unless you use an unintuitive hack. The OP
was proof that this is actually happening.
I think your starting point is wrong. The design does *not* fit
the purpose. We got Typedef to appease objections to 'typedef'
being removed from the language. And it did had the effect of
silencing the critics. We all expected Typedef to be a drop-in
replacement for typedef, not something with dangerously different
semantics.
Now, if, right from the beginning, you never expected Typedef to
replace typedef, then I can see why you think that Typedef is not
broken. (But in that case I have no idea what you thought Typedef
would be used for). Typedef solves the wrong problem, and solves
it well. But when you try to use it to solve the right problem,
you have to use an unintuitive hack.
But then it isn't very useful, either. You can't,
for example, use it to define the various Windows HANDLEs
(HMENU, etc),
which was one of the most successful use cases for D1's
typedef.
alias HMENU = Typedef!(void*, __MODULE__ ~ ".HMENU");
So please s/can't/can't the same exact way built-in typedef
would have
done it/.
No. You can hammer nails in using a rock, but I'm not prepared
to accept
a rock as a kind of hammer. It's not a tool that belongs in
any toolbox.
My assertion is, there are no use cases for Phobos's Typedef.
You're always better off doing something else.
But your evidence destroys your own assertion. Let me explain.
You bring the typo example as the smoking gun. So I take it
it's a biggie that, if fixed, would make you happy.
Not really. I showed that example simply to illustrate that the
complaint "this is ugly" is more than an personal preference.
It's ugly because it's a hack.
But there are a number of trivial fixes to it, such as my
defineTypedef above. So it looks like (a) Typedef can be used
as long as you are careful to not type the wrong name, (b) with
only trivial work, Typedef can be used without even the
slightest repetition.
So how come Typedef is unusable when it's usable by your own
testimony?
I have never said it couldn't be used. I said that it's usable,
in the same way that a rock is usable as a hammer. As a
substitute for a built-in typedef, it's not a library solution,
it's a library-supported hack.
And we should remove it before it leads more people astray.
