Re: No more multiline string constants

["Zack Weinberg" <zackw at Stanford dot EDU>]

On Thu, Jul 05, 2001 at 04:42:41PM -0700, Per Bothner wrote:
> "Zack Weinberg" <zackw@stanford.edu> writes:
> 
> > This patch removes the deprecated feature of multiline string
> > constants.
> 
> Just a minute!  I'm not sure we really agreed that this was a good
> idea.  I do know that Stallman is strongly opposed to removing this
> feature.  (It is possible this debate was internal to the steering
> commitee, in which case I apolize on behalf of the SC for not
> resolving and communicating this.)

I certainly was not aware of any such discussion.  Removing the
feature was discussed some time ago on the public lists, and it was
my impression that it had met with general approval.

I'd like to state my agreement with Geoff's statement that SC
discussions should be public.  I'd also like to state that in my
opinion, Stallman's opinion should count no more and no less than any
other experienced user's opinion.

> What is the reason for removing this feature, except that it is
> "non-standard", and there are other (standard) ways of achieving
> the same effect?  Note that those other standard ways are
> arguably quite a bit uglier.

There are three major arguments in my mind for removing the feature.

  - It is not merely an extension; it is a dangerous extension.

    Precisely because multiline strings are easy to use, and prettier
    than the standard alternatives, people use them.  GCC accepts them
    without comment, so many people think they are part of the
    standard.  However, there is no way to write code which makes use
    of multi-line strings only when compiled by GCC.  The poor schmuck
    who ports code to a different compiler therefore has to go back
    and edit them all.  It is easy to introduce errors while doing
    that.

    Extensions such as __attribute__, by contrast, are obviously
    specific to GCC, and can easily be rendered harmless when code is
    compiled with other compilers.

    I am aware that the official position of the FSF is that
    portability to other compilers is not terribly important.  I
    disagree with this position in the strongest possible terms.  We
    do no one a service by making it difficult to move code to other
    compilers.

  - Its semantics are ill-defined.

    For instance: is

"foo
bar"

    identical to "foo\nbar"?  What if the host and target have
    different line-ending conventions?  What if there is invisible
    whitespace between foo and the end of the line?

    GCC 2.7, 2.95, and 3.0 answer the above questions differently, and
    in no case are the answers documented.  And there are not
    obviously correct answers to any of them, nor have I enumerated
    all of the issues.

    This is the major reason why multi-line strings do not appear in
    the standard, incidentally.

  - It interferes with good diagnostics and error recovery.

    An accidental stray " in the middle of a line will cause the
    compiler to treat all code from then on as strings and all strings
    from then on as code.  The usual effect is a flood of useless
    error messages.  Without the extension, the compiler will get
    itself back in sync at the end of the line.

There is only one argument in my mind for keeping them:

  - It makes it easier to write lengthy chunks of inline assembly.

This is certainly true, however, writing a lengthy chunk of inline
assembly is almost always a mistake; it interferes with the compiler's
ability to do its job.  Therefore I do not think there is any
compelling need to make that easy.

-- 
zw        This is, no doubt, the rational strategy; quite possibly the
          only one that will work.  But it ignores the exigiencies of
          the tenure system and is therefore impractical.
          	-- Jerry Fodor, _The Mind Doesn't Work That Way_