Pure dynamic casts?

[Steven Schveighoffer]

On Tue, 22 Sep 2009 17:56:46 -0400, Jarrett Billingsley  
<jarrett.billingsley at gmail.com> wrote:

> On Tue, Sep 22, 2009 at 4:13 PM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>>> Dynamic downcasts do usually indicate a weakness in the design. But an
>>> even more fundamental matter of style is to not repeat yourself. You
>>> don't use "x + y" if you need the sum of x and y in ten places; you do
>>> "sum = x + y" and then use "sum." The same applies here. You're not
>>> just working around a deficiency in the compiler, you're saving
>>> yourself work later if you need to change all those values, and you're
>>> giving it some kind of semantic attachment by putting it in a named
>>> location.
>>
>> What if x and y are possibly changing in between calls to x + y?
>>
>> I'm thinking of a situation where o *might* be changing, but also might  
>> not,
>> the compiler could do some optimization to avoid the dynamic-cast calls  
>> in
>> the cases where it doesn't change.  These would be hard to code  
>> manually.
>>  My understanding of pure function benefits (and it's not that great) is
>> that you can express yourself how you want and the compiler fixes your  
>> code
>> to be more optimized knowing it can avoid calls.
>
> Realistically, how often is this going to come up? Why the hell are we
> looking at what amounts to CSEE on a rarely-used construct when there
> are far more important performance issues? I understand wanting to
> solve this problem for pedagogical reasons, but practically, I don't
> see the benefit.

Why have pure functions at all?  Seriously, all pure function reorderings  
and reuse can be rewritten by human optimization.  If we aren't going to  
look for places that pure functions can help optimize, why add them to the  
language, it seems more trouble than its worth?

If all it takes to optimize dynamic casts is to put pure on the function  
signature, have we wasted that much time?

-Steve