x.sizeof vs typeid(x)

[Tom S]

Sergey Gromov wrote:
> opIn has a distinct default semantics in the language.  It's 
> "check if," not an "apply to."  The ability to overload is here to mimic 
> the default semantics for non-ordinary types.  It's a bad practice IMO 
> to completely change operator semantics.

Well then, the whole C++ committee is following bad practice as well, by 
making << and >> work with streams. Following semantics is one thing - 
sure. It's crucial when you're making your own Map container to support 
it in exactly the same way as the built-in AAs do. But if you can make 
your code more natural to write by abusing the operators a little - 
opIn, operator<<, etc, then it's not a very bad practice IMHO. In fact, 
anyone defining opMul for their matrix class/struct is breaking 
semantics. The spec states that opMul is commutative.


> That's exactly why a 
> concatenation operator is added to D: to ensure that what you think is 
> being done is actually what is done, at least conceptually.

Wrong. As far as I know, it was added because D was supposed to have 
array operations, so you could say [1, 2] + [10, 10] and have [11, 12], 
not the concatenation.


> That's also the reason I didn't like the luabind library for C++. Here's 
> a piece of C++ code:
> 
>     module(L)
>     [
>         def("greet", &greet)
>     ];
> 
> What it does, God knows.

It doesn't really matter. Would you actually know without looking at the 
implementation? It's easy to read, the language features used can be 
figured out rather easily.
What matters is that it's really easy to use. It's actually a very nice 
example of a DSL (Domain Specific Language) within C++. Would you rather 
write 4 times this much, in order just to have it look like the rest of 
C++ code? Because then, there's the low level C API...


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode