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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
