3 ms·

You mean long %s stringnicely breaks upwith indentation and all" ? In my experience, this always gets ugly when you want to insert spaces (= about always).

You mean long %s stringnicely breaks upwith indentation and all" ? In my experience, this always gets ugly when you want to insert spaces (= about always). Do you put them at the end or at the start of each string (apart from the first or last string) I think scala’s mkString (https://superruzafa.github.io/visual-scala-reference/mkString/ https://superruzafa.github.io/visual-scala-reference/mkStrin...) is the best solution, visually, for such things, but unfortunately, it would require hackers in the parser to do the concatenation at compile time, where possible. Scala’s multiline strings look nice, too, if you want to insert newlines, except for the stripMargin thing (https://docs.scala-lang.org/overviews/scala-book/two-notes-about-strings.html https://docs.scala-lang.org/overviews/scala-book/two-notes-a...)

kazinator 5y ago
The spaces aren't the point of the comment; rather that we can break the literal into pieces and indent those pieces without affecting the contents. In a non-strawman real exmaple with real data, of course we include all the necessary spaces in the literals. However, this bug is easy to make in C; I've seen it numerous times.
- Someone 5y ago
  That’s preciseLy my point. This looks nice, but it’s too easy to forget tone of those spaces and to hard to spot that.
  - kazinator 5y ago
    I don't know of a good design that won't lead you to make errors when you don't want the spaces. You'd need some piece of syntax which indicates whether you want a space there or not. For instance, there could be a rule that a string literal ending in non-whitespace cannot joined with a literal starting with non-whitespace: "foo" "bar" // error "foo " "bar" // OK "foo" " bar" // OK "foo" "" "bar" // OK: "" doesn't start with non-whitespace, since it's empty "foo" " " "bar" // OK The nice thing about this is that it's perfectly comatible with existing C. All we have to do is to implement a compiler warning which detects when the rule is violated. Users who implement it have to fix situations like "foo" "bar" into "foo" "" "bar". Probably the rules should be smarter. Some kind of tokenization concept could be at play so that gluing together two letters or digits is bad, or two punctuation tokens, but letter/number and punctuation is okay. "foo" "1" // error? OK? "foo" "bar" // error "foo" ".bar" // OK "1." "2" ".3" // OK "1." ".2" // error: punct-punct

kazinator 5y ago

The spaces aren't the point of the comment; rather that we can break the literal into pieces and indent those pieces without affecting the contents. In a non-strawman real exmaple with real data, of course we include all the necessary spaces in the literals. However, this bug is easy to make in C; I've seen it numerous times.

Someone 5y ago
That’s preciseLy my point. This looks nice, but it’s too easy to forget tone of those spaces and to hard to spot that.
- kazinator 5y ago
  I don't know of a good design that won't lead you to make errors when you don't want the spaces. You'd need some piece of syntax which indicates whether you want a space there or not. For instance, there could be a rule that a string literal ending in non-whitespace cannot joined with a literal starting with non-whitespace: "foo" "bar" // error "foo " "bar" // OK "foo" " bar" // OK "foo" "" "bar" // OK: "" doesn't start with non-whitespace, since it's empty "foo" " " "bar" // OK The nice thing about this is that it's perfectly comatible with existing C. All we have to do is to implement a compiler warning which detects when the rule is violated. Users who implement it have to fix situations like "foo" "bar" into "foo" "" "bar". Probably the rules should be smarter. Some kind of tokenization concept could be at play so that gluing together two letters or digits is bad, or two punctuation tokens, but letter/number and punctuation is okay. "foo" "1" // error? OK? "foo" "bar" // error "foo" ".bar" // OK "1." "2" ".3" // OK "1." ".2" // error: punct-punct