Re: why Ada type casting is different from other languages? newType(value) vs. (newType)value

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 13.07.14 11:08, Dmitry A. Kazakov wrote:
> On Sun, 13 Jul 2014 12:01:26 +0300, Niklas Holsti wrote:
>
>> Ranting aside, the C form has the clear disadvantage that one must
>> remember precedence rules to understand what is being converted:
>>
>>    is (float)i the same as (float)i + j,
>>    or is it the same as (float)(i + j) ?
>>
>> In the Ada form, type(value), the parentheses nicely enclose the value
>> to be converted. Much better IMO.
>
> BTW, in Ada one need not remember precedence rules because all expressions
> where unary operation might be ambiguous are illegal:
>
>     not X and Y -- Illegal, brackets required
>     X and not Y -- That's OK


The bit about ambiguity is not meant to be a statement of a general truth?
Before the fact, is the following text unambiguous for a human reader?

    X : constant := 16#7F_FF#;

begin

    if not X in Unsigned_16'Range then  -- legal, brackets suggested
       raise Program_Error;
    end if;

(Yes, there are better ways to write this, but since you must know
them, the latter requirement wipes out some of the alleged advantage of Ada
in this regard, I think.)

I have read plausible justifications for the choice of type conversion syntax
of both Ada and C. But conceptually, I think that C++ has found a better
solution. It is more Ada like, perhaps, whenever C++ suggests to explicitly
state the intent:

    static_cast<float>(i + j)

seems pretty clear (even when it might be unnecessary). Ada's and C's
overloading of round brackets for several different things might be
tempting at first, but the temptation ceases once ease of understanding
the differences is considered more important. Of course, that's the time
when the phrase "every competent programmer ..." will be heard from all
camps, and then the ones about < and > !