or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at:
Re #fileliteral vs. #resourceliteral, I think the latter makes sense
because items are in the "Resources" folder of playgrounds. (The other day
I tried referencing a file outside the playground and was confused when
dragging it in made a copy.) You might also consider naming the parameter
resourceFileName instead of resourceName so it's clear that the file
extension is also required (which I assume it is(?)).
Is it necessary to include "literal" in the name? Isn't the fact that
there's special compiler support enough to indicate that it's a
literal-like value?
Jacob
···
On Mon, Mar 7, 2016 at 3:54 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
Hello Swift community,
The review of “ Modernizing Playground Literals” begins now and runs
through March 9, 2016. The proposal is available here:
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
*What goes into a review?*
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to
Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
More information about the Swift evolution process is available at:
• Is the problem being addressed significant enough to warrant a
change to Swift?
Though this change only applies to playgrounds, the current syntax is
definitely odd, and doesn't match anything else in the language. For
beginners to swift who may be using playgrounds extensively, seeing the
current syntax behind the scenes might lead them to be confused by how
dissimilar it is to anything else. If parsing of these literals in
playgrounds can be made simpler and faster by this change, then that is
another positive outcome.
• Does this proposal fit well with the feel and direction of Swift?
I believe so. Using the increasingly common # syntax in a unified way
helps simplify things.
• If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
I've used racket in the past which has support for dragging images
inline in the repl/code editor, but I haven't looked into how that is
represented as text. I can't imagine it uses anything comparably
unconventional like the existing swift syntax though.
• How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
A quick read through of the proposal and some reading of the preceding
email thread.
+1. I have a slight preference for “fileliteral” over “resourceliteral”. I don’t see a great advantage of one over the other, so I’d use the name that is closer to the existing terminology just so it’s more apparent that the functionality hasn’t changed, only the syntax.
Is the problem being addressed significant enough to warrant a change to Swift?
Although playground literals are "hidden" when editing the playground in Xcode, the source code is still relevant. So yes, I think it is.
Does this proposal fit well with the feel and direction of Swift?
Definetely. As playground literals are de facto compiler directives, the new syntax matches the naming convention of compiler directives. The `[# #]` syntax feels very out-of-place in Swift.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
No other language I used has such literals, so no.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the proposal.
Pozdrawiam – Regards,
Adrian Kashivskyy
···
Wiadomość napisana przez Chris Lattner via swift-evolution <swift-evolution@swift.org> w dniu 08.03.2016, o godz. 00:54:
Hello Swift community,
The review of “ Modernizing Playground Literals” begins now and runs through March 9, 2016. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at:
1. To create an identifier that was long and unique enough to avoid the naming conflict previously experienced with #line for debug identifiers.
2. To clarify the role of the constructor, which is to create a literal playground reference, that can then be copied, dragged, etc within the playground editor.
3. To properly modify the constructor name rather than the argument name.
Other notes:
* There's a consistent use of lowercase identifiers rather than camelCase, which this proposal follows.
* While I personally prefer resourceliteral, fileliteral more closely followed the current art so got preferential mention.
* At some future date, I'd like to see the playground literal vocabulary expand (for example, URL) but that falls outside the scope of this proposal.
-- Erica
···
On Mar 7, 2016, at 5:15 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:
+1; quick read.
Re #fileliteral vs. #resourceliteral, I think the latter makes sense because items are in the "Resources" folder of playgrounds. (The other day I tried referencing a file outside the playground and was confused when dragging it in made a copy.) You might also consider naming the parameter resourceFileName instead of resourceName so it's clear that the file extension is also required (which I assume it is(?)).
Is it necessary to include "literal" in the name? Isn't the fact that there's special compiler support enough to indicate that it's a literal-like value?
Jacob
On Mon, Mar 7, 2016 at 3:54 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello Swift community,
The review of “ Modernizing Playground Literals” begins now and runs through March 9, 2016. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at: