Re: simply question about syntatic sugar

[Nagaev Boris <bnagaev@...>]

On Mon, Jun 8, 2015 at 2:31 AM, Coda Highland <chighland@gmail.com> wrote:
> On Sun, Jun 7, 2015 at 5:54 PM, Brigham Toskin <brighamtoskin@gmail.com> wrote:
>> On Sun, Jun 7, 2015 at 3:10 PM, Coda Highland <chighland@gmail.com> wrote:
>>>
>>> Do you really think it's safer to use identical syntax for member
>>> access when the two types are otherwise handled entirely differently?
>>
>>
>> Counterpoint: C++ object references and Lua UserData with metatables. They
>> look (and at a shallow level, act) like completely different data types (the
>> type referred to, and a table, respectively). I don't hear very many people
>> complaining about this convenience, or calling it intrinsically unsafe. But
>> maybe that's just because we're drinking the kool-aid?
>
> Counter-counterpoint: I'm a diehard C++ developer. ;)
>
> Okay, that wasn't the actual counter-counterpoint.
>
> The thing is, object references in C++ were actually explicitly
> DESIGNED to address the problems with pointers. They actually DON'T
> have substantially different semantics from the object itself. You
> can't reassign an object reference point to a different instance; if
> you assign to an object reference, it behaves exactly the same as
> assignment to the original object. Accessing the elements of an object
> reference has the same semantics as accessing the elements of the
> object itself. You know that there's exactly one object on the other
> side of the reference; there's no ambiguity over whether it's 0
> (null), 1 (pointer), or many (array). You don't have to worry about
> the memory management of a reference.

Disagree. If a pointed object is deleted, than a reference becomes a
dangling reference (not better than dangling pointer). By the way,
Rust developers say this problem is addressed in Rust.

>
> The only exception is that two object references can alias to the same
> backing object. Aliasing is, of course, the entire reason for object
> references to exist. In my opinion, the fact that you have to mark
> references with a & in the type signature is sufficiently different
> syntax for how little the semantics differ.
>
> (Self-nitpick: Okay, there IS another exception when it comes to using
> references as template parameters, because that's operating at a
> different level of abstraction. However, the exception goes away after
> template expansion is complete, and technically it's a difference in
> the semantics of the types as types rather than a difference in the
> semantics of the variables declared with those types.)
>
> (Self-nitpick the second: Okay, so sizeof() returns different values
> for a structure containing a reference and a structure containing
> another object. Whether this counts as a semantic difference is a
> pretty nitpicky argument, as it doesn't impact very much at all except
> that you can't interchange the two objects -- but you can't
> interchange the two objects ANYWAY because they're of different
> types.)
>
> /s/ Adam
>



-- 


Best regards,
Boris Nagaev