-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
two proposals for more elegant syntax #11
Conversation
pinxue
commented
Dec 3, 2015
- use $(expr) to replace (expr) for string literal interpolation.
- add const as an alias for let.
I dont agree with both:
In general, these two proposals seem to come from a wish to make Swift syntax more similar to languages the author is more fluent in. I don't think this is a good reason for accepting then. |
I agree with @harbit - these changes are purely syntactical, which is are opinionated and don't have enough motivation to make them worthwhile (IMO). |
I agree with @hartbit as well. Changing string interpolation from \ to $ doesn't seem ideal to me. Most languages have some character to denote that it's a string interpolation. Using \ is the most consistent since it's the same as other escape characters. This would also break tons of Swift code. A keyword alias would only cause confusion in my opinion. |
|
||
## Impact on existing code | ||
|
||
It is harmless new syntax sugar, thus no impacts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd argue two keywords to do the same thing would be confusing to new Swift programmers.
I love the enthusiasm here, but the intent is for changes to be discussed on the swift-evolution mailing list first. Pull requests with complete proposals are a later stage in the process, once an idea has been discussed and refined. Please see the Swift Evolution Process document (process.md) in this repository for more information. |
@pinxue love to see proposals from others in the community though! ❤️ |
Only if I can get mailing list page displayed... |
* Initial revision of task executors proposal * Cleanup and remove unclear pieces of design * add missing withTaskExecutor in snippet * Update NNNN-task-executor-preference.md * remove ordering promises; they are not strictly guaranteed * preference also affects default actors * introduce the notion of TaskExecutor, in order to handle default actors * change title * add some warnings about when to use this proposal * arrow typo in diagram * Fix typo (#11) Fixed a little typo * Fixed typo. (#12) * Update missed section; SerialExecutors are NOT TaskExecutors by default * Explain Task(on actor) a bit more -- in future directions * fix typo in async let example * add unownedTaskExecutor API * minor rewording in sentence * document that executor can be both serial and task executor * add minor notes to serial+task executor section * Apply suggestions from code review Co-authored-by: Doug Gregor <[email protected]> * Update NNNN-task-executor-preference.md * Cleanup a comment * Update proposals/NNNN-task-executor-preference.md Co-authored-by: John McCall <[email protected]> --------- Co-authored-by: Genaro-Chris <[email protected]> Co-authored-by: Wade Tregaskis <[email protected]> Co-authored-by: Doug Gregor <[email protected]> Co-authored-by: John McCall <[email protected]>
Update Future Direction: Lifetime dependence for closures