Swift multiline string literal prototype

literal.swift

#!/usr/bin/env xcrun swift

// This code sample and prototype implementation (implemented in patch against the 3.0
// branch of the swift compiler) explores a possible syntax based on ideas discussed in
// the swift-evolution mailing list at
//      http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133
//
// The proposed syntax uses a combination of two characters to signal the start and end 
// of a multiline string in the source code:   _" contents "_ 
// 
// Additionally, the syntax introduces a new @string_literal() attibute that can be used
// to semantically tag the contents of a multiline string literal. The hope is that this
// attribute would be used by IDEs for custom validation/formatting of the contents of 
// long string literals, as well as possibly be accessible at runtime via an extended
// mirror/reflection mechanism.

// Tagging literal contents
@string_literal("json")       let att1 = _"{"key1": "stringValue"}"_
@string_literal("text/xml")   let att2 = _"<catalog><book id="bk101" empty=""/></catalog>"_
@string_literal("swift_sil")  let att3 = _" embedded SIL contents?! "_

// The following alternatives for placement of the attribute have been looked into 
// and so far rejected for seemingly not fitting as closely with other attribute usage 
// patterns in the Swift grammar:
// 
// let att2 : @string_literal("text/xml") String  = _" ... "_  // Conveys the impressing that the type is annotated rather than the variable
// let att2 = @string_literal("text/xml") _" ... "_            // Appealing, but without any precedent in the Swift grammar
//

// checking that nothing is broken
let s0 = "s0"

// The default swift syntax requires that quotes be escaped
let s1 = "{\"key1\": \"stringValue\"}"

// The proposed syntax for multiline strings works for single line strings as well (maybe it 
// should not) and does not mandate that enclosed single quote characters be escaped
let s2 = _"{"v2"}"_

// When dealing with long blocks of embedded text, it seems natural to want to describe them
// as close as possible to the contents. The proposed syntax supports inserting a comment
// just before the data it documents. This allows the comment indentation to match exactly
// that of the string.
let s3 =
    /* this is a template */
    _"{"key3": "stringValue"}"_

// --------------------------------------------------------------------------------
// The following section explores different ways to deal with leading spaces

let s4 =
/* this is (almost) the same template */
_"
{
  "key4": "stringValue"
  , "key2": "stringValue"
}
"_

let equivS4 = 
"\n"
"{\n" +
"  \"key4\": \"stringValue\"\n" +
"  , \"key2\": \"stringValue\"\n" +
"}\n" +
"\n"

//TODO: fix the leading spaces
let s5 =
  /* this is exactly the same template as s5 */
  _"
  {
    "key5": "stringValue"
  }
  "_

//TODO: fix the leading spaces
let s6 =
  /* this is exactly the same template as s5 */
  _"
  |{
  |  "key6": "stringValue"
  |  , "key2": "stringValue"
  |}
  "_

// -----------------------------------------------------------------------

print(s2)
print(s3)
print(s4)
print(s5)
print(s6)

output

{"v2"}
{"key3": "stringValue"}

{
  "key4": "stringValue"
  , "key2": "stringValue"
}


  {
    "key5": "stringValue"
  }


  |{
  |  "key6": "stringValue"
  |  , "key2": "stringValue"
  |}