Re: Issue 5310: find_top_context () maintenance (issue 341150043 by address@hidden)

[dak]

On 2018/04/22 13:56:01, Dan Eble wrote:
> On 2018/04/22 13:37:50, dak wrote:
> > So again I don't see what problem you are trying to solve.

> 1. find_something(...)->blahblah()
> I have no idea whether that will call blahblah() with a valid instance
of
> something.

C++ does not allow "this" to be 0, so you have the syntactic guarantee
that it will not be 0 or you will have undefined behavior.

> 2. find_something(...).blahblah()
> I know will call blahblah() with a valid instance of something.

*p is not a valid reference if p is 0, so you have the syntactic
guarantee that it will not be 0 or you will have undefined behavior.

Basically you don't change when behavior is undefined but still mess up
the syntax and the relation between SCM and C++ pointers.

> > Basically you want to abuse reference notation as some kind of value
passing
> > contract, mixing up semantics and syntax in the process.

> I don't understand your concerns, but this change is not that
important to me,
> so I will withdraw it.  "If it can't be null, use a reference" has
been the rule
> of thumb at work for almost two decades, but LilyPond is older than
that, so I
> will try to cope with it.

When your work location confuses reference notation with a value passing
contract, that's not a problem of the age of LilyPond.

"This cannot be zero because surely Peter would not introduce undefined
behavior lightly." is not a value passing contract.

  assert (p);

is explicit if you need that and does not require messing with
references.  The main purpose of references is to avoid spurious
temporary copies in large-size structures used in value context or for
user-defined operators.

Not for managing heap-only objects with identity rather than value, and
things like contexts _are_ carrying identity.

> > Part of the reason is that the identity can be
> > verified by pointer comparison, and that is what eq? does in the
Scheme world.


> I would like to understand this statement a little better for my own
benefit.
> The address of a referenced object can be obtained with operator &.
It isn't
> lost.

But it makes the address a property of the object rather than the
fundamental entity conveying its identity.  And you can take the address
of temporary copies/values/variable as well in that manner: depending on
what copy contructors and whatever do, you don't get the address of
_the_ object but just _some_ address of something having the same value.
 It's not something you would want to compare or sort on.

There is a difference between const references and variable references
involved here as well (variable references are not magically attaching
themselves to temporary copies, but const references may do so).  When
passing around pointers rather than references, there are no copies
created silently either way.

Basically the semantic guarantees you are aiming for here are just not
there either way (the undefined behavior starts at a different point but
is still undefined) but the semantics of references match worse for our
identity-carrying heap objects that those of pointers.

https://codereview.appspot.com/341150043/