Re: Use a pointer for the output parameter of Lily_lexer::scan_word (issue 577440044 by address@hidden)

[David Kastrup]

address@hidden writes:

>> Stop using non-const references in function signatures
>
> Carrying the discussion over from [1], I would like to hear a clear
> decision that this is the way LilyPond is going to be coded--something
> more definite than one person proposing a change and another saying it
> looks good.  If this is the way things are going to be, contributors and
> reviewers would also benefit from guidance on when a function should
> validate the pointers it receives, and if it doesn't, how that ought to
> be documented to make up for not being allowed to pass by reference.
>
> [1] https://codereview.appspot.com/577410045/
>
>
> https://codereview.appspot.com/577440044/

My own definite rule here would be:

Don't pass objects with a Scheme-determined lifetime by reference.  Use
pointers instead.  "Scheme-determined" may be replaced with "dynamic
lifetime" for general C++ code, but I don't think we really have all
that much new/delete outside of SCM handling.  But for example an
additional output parameter of SCM type itself in my book already
warrants passing by reference.  Which would include this particular
issue.

I would not have chosen this way if I had not thought it the most
appropriate.  It's actually a fairly recent commit, namely

commit cc9f25fa7ad9eecd1d1d9cfc2b3c50d96a847386
Author: David Kastrup <address@hidden>
Date:   Sat Apr 1 14:54:05 2017 +0200

    Issue 5113/1: Reorganize Lily_lexer::scan_bare_word
    
    This also redefines LilyPond's manners of converting simple
    expressions into music, most notably checking drum types for being
    defined before accepting them as note values.

We don't actually have a lot of functions having to, in essence, return
more than a single value so actually _either_ passing a pointer or
reference for that purpose is quite rare in the code base.  So I would
not call this use of a reference exceptional: we don't use pointers for
that purpose a lot either.

-- 
David Kastrup