[swift-evolution] [Discussion] Modernizing Playground Literals

[Erica Sadun]

Ken Orr also gave it his blessing if that counts.

-- Erica

> On Feb 16, 2016, at 10:03 AM, Chris Lattner <clattner at apple.com> wrote:
> 
> 
>> On Feb 15, 2016, at 12:16 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Presented for discussion and feedback. Thank you in advance for your thoughts.
> 
> Hi Erica,
> 
> You already know this, but big +1 from me.  This is a syntactic construct that people are not supposed to see (which is why I’m not surprised you’re getting no feedback on the list) but it is important for us to pull the syntax inline with everything else, for consistency in the parser.
> 
> -Chris
> 
> 
>> 
>> -- Erica
>> 
>> Modernizing Playground Literals
>> 
>> Proposal: TBD
>> Author(s): Erica Sadun <http://github.com/erica>
>> Status: TBD
>> Review manager: TBD
>>  <https://gist.github.com/erica/b377a1abb53414b7a9f2#introduction>Introduction
>> 
>> Playground literals tokenize colors, files, and images. They provide drag-and-drop convenience and in-context visualizations that offer easy reference and manipulation when designing playground content. These literals are built using a simple square bracket syntax that, in the current form, conflicts with collection literals. This proposal redesigns playground literals to follow the precedent of #available and #selector.
>> 
>> Thanks to Chris Lattner <https://github.com/lattner> for suggesting this enhancement.
>> 
>>  <https://gist.github.com/erica/b377a1abb53414b7a9f2#motivation>Motivation
>> 
>> Color, image, and file literals are currently represented as:
>> 
>> [#Color(colorLiteralRed: red, green: green, blue: blue, alpha: alpha)#]
>> [#Image(imageLiteral: localResourceNameAsString)#]
>> [#FileReference(fileReferenceLiteral: localResourceNameAsString)#]
>> Playground literals present the following features:
>> 
>> They appear within a container designated with [# #] endpoints. 
>> They are marked with a capital camel case role name.
>> First label arguments use the word literal to punch the construction of each literal item.
>> There are several issues with this approach:
>> 
>> The enclosing square brackets conflict with collection literals, adding extra work for parsing. 
>> The construction syntax does not follow modern Swift conventions.
>> The word literal describes the constructed items not the argument being passed to create the literal. It is misplaced in its current use.
>>  <https://gist.github.com/erica/b377a1abb53414b7a9f2#detail-design>Detail Design
>> 
>> Simplifying constructors to octothorpe <https://en.wikipedia.org/wiki/Octothorpe>-delineated identifiers cleans up the language, removes potential grammar conflicts, and follows precedent for other identifiers used in modern Swift. Our proposed identifiers are #colorliteral, #imageliteral, and #fileliteral.
>> 
>> color-literal → #colorliteral(red: unit-floating-point-literal, green: unit-floating-point-literal, blue: unit-floating-point-literal, alpha: unit-floating-point-literal)
>> unit-floating-point-literal → floating point number greater or equal to zero, less than or equal to one
>> 
>> image-literal → #imageliteral(name: image-resource-name)
>> image-resource-name → static-string-literal referring to image resource name
>> 
>> file-literal → #fileliteral(resourceName: file-resource-name)
>> file-resource-name → static-string-literal referring to local resource name
>> In this design:
>> 
>> Each redesigned identifier uses lower case, to match existing Swift literals.
>> Arguments use lower camel case labels, as is conventional.
>> The word literal is added to identifiers denoting each item's role.
>> The arguments are simplified and standardized to red, green, blue, alpha, imageName, and resourceName.
>>  <https://gist.github.com/erica/b377a1abb53414b7a9f2#alternatives-considered>Alternatives Considered
>> 
>> #resourceliteral may better describe a file resource than #fileliteral.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160216/19bfde8a/attachment.html>