I often have related variables. Would be nice to just add ' like I can in Haskell:
let foo = "asdf"let foo' = "asdf2"
What do you think?
It's not as easy to type, but you can already use U+02B9 MODIFIER LETTER
PRIME for this purpose. Swift accepts this:
let x = 1
let xʹ = x + 1
let xʹʹ = xʹ + 1
let xʹʹʹ = xʹʹ + 1
···
On Wed, Jan 11, 2017 at 7:08 AM, Tuur Anton via swift-evolution < swift-evolution@swift.org> wrote:
I often have related variables. Would be nice to just add ' like I can in
Haskell:let foo = "asdf"
let foo' = "asdf2"What do you think?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-1. Why? Why not use foo2 instead? Is ' so much better?
Instead, I'd personally love better character support in Swift in the future and allow a Character literals using ' - just like in C, except with Unicode support:
let myChar = 'x' // Character
let myChar2 = '∃' // Character
let myChar3 = '\0' // NUL Character
let myChar4 = 'xyz' // Error from compiler
···
On Jan 11, 2017, at 2:08 PM, Tuur Anton via swift-evolution <swift-evolution@swift.org> wrote:
I often have related variables. Would be nice to just add ' like I can in Haskell:
let foo = "asdf"
let foo' = "asdf2"What do you think?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Ooooh… the mathematician in me would love that.
let foo = …
let foo’ = …
let foo’’ = …
let foo’’’ = …
But I suspect the additional complexity to the parser isn’t worth it. When are two bars just two bars, and when are they an empty string literal?
Karl
···
On 11 Jan 2017, at 14:08, Tuur Anton via swift-evolution <swift-evolution@swift.org> wrote:
I often have related variables. Would be nice to just add ' like I can in Haskell:
let foo = "asdf"
let foo' = "asdf2"What do you think?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I can't think of any instances where it'd be ambiguous... An empty character literal tacked on to the end of an identifier is a syntax error, right? Likewise if you've got an empty literal just hanging out in the middle of a statement, that's a syntax error as well. "=", "(", and such are all invalid identifier characters, so you couldn't name something that might be confused with an assignment or anything... I can't speak to the difficulty of implementing this, but I don't think it'd break anything. OTOH, I woke up about 5 minutes ago and haven't had my coffee yet.
My inner mathematician would be very happy indeed... +1
- Dave Sweeris
···
On Jan 11, 2017, at 07:43, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:
On 11 Jan 2017, at 14:08, Tuur Anton via swift-evolution <swift-evolution@swift.org> wrote:
I often have related variables. Would be nice to just add ' like I can in Haskell:
let foo = "asdf"
let foo' = "asdf2"What do you think?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolutionOoooh… the mathematician in me would love that.
let foo = …
let foo’ = …
let foo’’ = …
let foo’’’ = …But I suspect the additional complexity to the parser isn’t worth it. When are two bars just two bars, and when are they an empty string literal?
These aren't necessarily mutually exclusive. If we require that an identifier can't start with an apostrophe, then we can support identifiers named `x'` and `'x'` as some kind of literal simultaneously.
I'm sympathetic to this since I personally find x', x'', etc. more attractive than x2, x3, etc. for totally superficial math weenie reasons, but although the surface level language design is fairly straightforward, the downstream tooling impact is nontrivial—we'd need a mangling for ' in symbol names, simplified parsing tools would need to cope with ', tools that attempt to parse out identifiers from error messages would have to deal with apostrophe-unsafe output, etc. Not sure it's worth it.
-Joe
···
On Jan 11, 2017, at 5:16 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:
-1. Why? Why not use foo2 instead? Is ' so much better?
Instead, I'd personally love better character support in Swift in the future and allow a Character literals using ' - just like in C, except with Unicode support:
let myChar = 'x' // Character
let myChar2 = '∃' // Character
let myChar3 = '\0' // NUL Character
let myChar4 = 'xyz' // Error from compiler
This feature was removed (just before the first Swift 1.0 beta). Search for "Single-quoted literals are no longer recognized" in the CHANGELOG.
<https://github.com/apple/swift/blob/master/CHANGELOG.md#2014-05-13>
I'm looking forward to the "String re-evaluation" part of Swift 4 stage 1. Hopefully, the Character type will also be improved.
-- Ben
···
On 11 Jan 2017, at 13:16, Charlie Monroe wrote:
Instead, I'd personally love better character support in Swift in the future and allow a Character literals using ' - just like in C, except with Unicode support:
let myChar = 'x' // Character
let myChar2 = '∃' // Character
let myChar3 = '\0' // NUL Character
let myChar4 = 'xyz' // Error from compiler
Out of curiosity, instead of coming up with another mangling scheme, how hard would it be to add ' support to the downstream tooling? It's all open source, right?
- Dave Sweeris
···
On Jan 11, 2017, at 15:41, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 5:16 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:
-1. Why? Why not use foo2 instead? Is ' so much better?
Instead, I'd personally love better character support in Swift in the future and allow a Character literals using ' - just like in C, except with Unicode support:
let myChar = 'x' // Character
let myChar2 = '∃' // Character
let myChar3 = '\0' // NUL Character
let myChar4 = 'xyz' // Error from compilerThese aren't necessarily mutually exclusive. If we require that an identifier can't start with an apostrophe, then we can support identifiers named `x'` and `'x'` as some kind of literal simultaneously.
I'm sympathetic to this since I personally find x', x'', etc. more attractive than x2, x3, etc. for totally superficial math weenie reasons, but although the surface level language design is fairly straightforward, the downstream tooling impact is nontrivial—we'd need a mangling for ' in symbol names, simplified parsing tools would need to cope with ', tools that attempt to parse out identifiers from error messages would have to deal with apostrophe-unsafe output, etc. Not sure it's worth it.
Instead, I'd personally love better character support in Swift in the future and allow a Character literals using ' - just like in C, except with Unicode support:
let myChar = 'x' // Character
let myChar2 = '∃' // Character
let myChar3 = '\0' // NUL Character
let myChar4 = 'xyz' // Error from compilerThis feature was removed (just before the first Swift 1.0 beta). Search for "Single-quoted literals are no longer recognized" in the CHANGELOG.
I'm aware of that and think it's a shame. When you need a Character, you either need to declare the variable with type:
let c: Character = "a"
or use the initializer (which I prefer):
let c = Character("a")
--- but here, this is valid:
let c = Character("ax")
and will compile, yet crash at runtime.
I really hope that special syntax (single-quotes, or any other) is introduced back in the future.
···
On Jan 11, 2017, at 3:55 PM, Ben Rimmington <me@benrimmington.com> wrote:
On 11 Jan 2017, at 13:16, Charlie Monroe wrote:
<https://github.com/apple/swift/blob/master/CHANGELOG.md#2014-05-13>
I'm looking forward to the "String re-evaluation" part of Swift 4 stage 1. Hopefully, the Character type will also be improved.
-- Ben
Much of it is open source, but there's no telling how much other code is out there, and we'd have to find out. swiftc itself for instance already delimits identifier names with apostrophes in diagnostics, and while there are APIs for consuming the compiler's diagnostics in more readily parsable formats like JSON, there's no guarantee ad-hoc tools are using them properly.
-Joe
···
On Jan 11, 2017, at 2:07 PM, David Sweeris <davesweeris@mac.com> wrote:
On Jan 11, 2017, at 15:41, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 5:16 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:
-1. Why? Why not use foo2 instead? Is ' so much better?
Instead, I'd personally love better character support in Swift in the future and allow a Character literals using ' - just like in C, except with Unicode support:
let myChar = 'x' // Character
let myChar2 = '∃' // Character
let myChar3 = '\0' // NUL Character
let myChar4 = 'xyz' // Error from compilerThese aren't necessarily mutually exclusive. If we require that an identifier can't start with an apostrophe, then we can support identifiers named `x'` and `'x'` as some kind of literal simultaneously.
I'm sympathetic to this since I personally find x', x'', etc. more attractive than x2, x3, etc. for totally superficial math weenie reasons, but although the surface level language design is fairly straightforward, the downstream tooling impact is nontrivial—we'd need a mangling for ' in symbol names, simplified parsing tools would need to cope with ', tools that attempt to parse out identifiers from error messages would have to deal with apostrophe-unsafe output, etc. Not sure it's worth it.
Out of curiosity, instead of coming up with another mangling scheme, how hard would it be to add ' support to the downstream tooling? It's all open source, right?
As Rob Mayoff pointed out, you can use MODIFIER LETTER PRIME - or PRIME,
DOUBLE PRIME, and TRIPLE PRIME - which makes more sense than an apostrophe.
Now if only there were a keyboard that had a touch-screen at the top which
could be used for typing context-sensitive characters that would otherwise
be difficult to type. So yeah, solution is to make characters easier to
type, not modify the language. If like me you don't have such a keyboard,
you can always use ctrl+⌘+<space> and type ‘PRIME’ to find it, then pick it
from recently used/favourites.
Regarding the other point, I agree that character literals would be handy,
but again I’m not sure if apostrophe is the right character to indicate it.
Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT
SINGLE QUOTATION MARK would be better, they can be relatively easily typed
with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes
into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.
-1. Why? Why not use foo2 instead? Is ' so much better?
Instead, I'd personally love better character support in Swift in the
future and allow a Character literals using ' - just like in C, except with
Unicode support:
let myChar = 'x' // Character
let myChar2 = '∃' // Character
let myChar3 = '\0' // NUL Character
let myChar4 = 'xyz' // Error from compilerThese aren't necessarily mutually exclusive. If we require that an
identifier can't start with an apostrophe, then we can support identifiers
named `x'` and `'x'` as some kind of literal simultaneously.
I'm sympathetic to this since I personally find x', x'', etc. more
attractive than x2, x3, etc. for totally superficial math weenie reasons,
but although the surface level language design is fairly straightforward,
the downstream tooling impact is nontrivial—we'd need a mangling for ' in
symbol names, simplified parsing tools would need to cope with ', tools
that attempt to parse out identifiers from error messages would have to
deal with apostrophe-unsafe output, etc. Not sure it's worth it.
Out of curiosity, instead of coming up with another mangling scheme, how
hard would it be to add ' support to the downstream tooling? It's all open
source, right?
- Dave Sweeris
···
On Wed, 11 Jan 2017 at 22:07 David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 15:41, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:
On Jan 11, 2017, at 5:16 AM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote:
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Please yes, if reasonably possible.
I can see how it might not be though.
···
On Wed, Jan 11, 2017 at 7:46 PM, Jay Abbott via swift-evolution < swift-evolution@swift.org> wrote:
As Rob Mayoff pointed out, you can use MODIFIER LETTER PRIME - or PRIME,
DOUBLE PRIME, and TRIPLE PRIME - which makes more sense than an apostrophe.
Now if only there were a keyboard that had a touch-screen at the top which
could be used for typing context-sensitive characters that would otherwise
be difficult to type. So yeah, solution is to make characters easier to
type, not modify the language. If like me you don't have such a keyboard,
you can always use ctrl+⌘+<space> and type ‘PRIME’ to find it, then pick
it from recently used/favourites.Regarding the other point, I agree that character literals would be handy,
but again I’m not sure if apostrophe is the right character to indicate it.
Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT
SINGLE QUOTATION MARK would be better, they can be relatively easily typed
with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes
into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.On Wed, 11 Jan 2017 at 22:07 David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:
> On Jan 11, 2017, at 15:41, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> On Jan 11, 2017, at 5:16 AM, Charlie Monroe via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> -1. Why? Why not use foo2 instead? Is ' so much better?
>>
>> Instead, I'd personally love better character support in Swift in the
future and allow a Character literals using ' - just like in C, except with
Unicode support:
>>
>> let myChar = 'x' // Character
>> let myChar2 = '∃' // Character
>> let myChar3 = '\0' // NUL Character
>> let myChar4 = 'xyz' // Error from compiler
>
> These aren't necessarily mutually exclusive. If we require that an
identifier can't start with an apostrophe, then we can support identifiers
named `x'` and `'x'` as some kind of literal simultaneously.
>
> I'm sympathetic to this since I personally find x', x'', etc. more
attractive than x2, x3, etc. for totally superficial math weenie reasons,
but although the surface level language design is fairly straightforward,
the downstream tooling impact is nontrivial—we'd need a mangling for ' in
symbol names, simplified parsing tools would need to cope with ', tools
that attempt to parse out identifiers from error messages would have to
deal with apostrophe-unsafe output, etc. Not sure it's worth it.Out of curiosity, instead of coming up with another mangling scheme, how
hard would it be to add ' support to the downstream tooling? It's all open
source, right?- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
As Rob Mayoff pointed out, you can use MODIFIER LETTER PRIME - or PRIME,
DOUBLE PRIME, and TRIPLE PRIME - which makes more sense than an apostrophe.
Now if only there were a keyboard that had a touch-screen at the top which
could be used for typing context-sensitive characters that would otherwise
be difficult to type. So yeah, solution is to make characters easier to
type, not modify the language. If like me you don't have such a keyboard,
you can always use ctrl+⌘+<space> and type ‘PRIME’ to find it, then pick
it from recently used/favourites.Regarding the other point, I agree that character literals would be handy,
but again I’m not sure if apostrophe is the right character to indicate it.
Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT
SINGLE QUOTATION MARK would be better, they can be relatively easily typed
with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes
into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.
I'm not entirely convinced that we *need* special Character literals. The
type checker is already able to treat a double-quoted string literal as a
String, Character, or UnicodeScalar based on context in most places.
Wouldn't it be more valuable to fill the gaps, like Charlie Monroe
mentioned above, where these work:
let c: Character = "a"
let c = "a" as Character
and this is caught as an error by the compiler:
let c: Character = "ax"
but this slips through and crashes at runtime?
let c = Character("ax")
I wonder what improvements could be made in the compiler to have that last
one do something more appropriate than just call Character.init(String),
which causes the runtime error.
···
On Wed, Jan 11, 2017 at 6:46 PM Jay Abbott via swift-evolution < swift-evolution@swift.org> wrote:
On Wed, 11 Jan 2017 at 22:07 David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:
> On Jan 11, 2017, at 15:41, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> On Jan 11, 2017, at 5:16 AM, Charlie Monroe via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> -1. Why? Why not use foo2 instead? Is ' so much better?
>>
>> Instead, I'd personally love better character support in Swift in the
future and allow a Character literals using ' - just like in C, except with
Unicode support:
>>
>> let myChar = 'x' // Character
>> let myChar2 = '∃' // Character
>> let myChar3 = '\0' // NUL Character
>> let myChar4 = 'xyz' // Error from compiler
>
> These aren't necessarily mutually exclusive. If we require that an
identifier can't start with an apostrophe, then we can support identifiers
named `x'` and `'x'` as some kind of literal simultaneously.
>
> I'm sympathetic to this since I personally find x', x'', etc. more
attractive than x2, x3, etc. for totally superficial math weenie reasons,
but although the surface level language design is fairly straightforward,
the downstream tooling impact is nontrivial—we'd need a mangling for ' in
symbol names, simplified parsing tools would need to cope with ', tools
that attempt to parse out identifiers from error messages would have to
deal with apostrophe-unsafe output, etc. Not sure it's worth it.Out of curiosity, instead of coming up with another mangling scheme, how
hard would it be to add ' support to the downstream tooling? It's all open
source, right?- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
So yeah, solution is to make characters easier to type, not modify the language.
+1
If like me you don't have such a keyboard, you can always use ctrl+⌘+<space> and type ‘PRIME’ to find it, then pick it from recently used/favourites.
Regarding the other point, I agree that character literals would be handy, but again I’m not sure if apostrophe is the right character to indicate it. Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT SINGLE QUOTATION MARK would be better, they can be relatively easily typed with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.
I think the single (ASCII) quote is standard enough for use as a character delimiter.
This reminds me of the "URL literal" thread. I believe the two ideas were essentially to add regex support to the compiler, add support for compiler "validation" of literals through compile-time functions, or both.
IIRC, it was decided that both ideas were at least out of scope for phase 1 (I don't recall if this specific issue was brought up as a potential use case, though... unlike `Character`, `URL` isn't part of the stdlib).
- Dave Sweeris
···
On Jan 11, 2017, at 23:12, Tony Allevato <tony.allevato@gmail.com> wrote:
On Wed, Jan 11, 2017 at 6:46 PM Jay Abbott via swift-evolution <swift-evolution@swift.org> wrote:
As Rob Mayoff pointed out, you can use MODIFIER LETTER PRIME - or PRIME, DOUBLE PRIME, and TRIPLE PRIME - which makes more sense than an apostrophe. Now if only there were a keyboard that had a touch-screen at the top which could be used for typing context-sensitive characters that would otherwise be difficult to type. So yeah, solution is to make characters easier to type, not modify the language. If like me you don't have such a keyboard, you can always use ctrl+⌘+<space> and type ‘PRIME’ to find it, then pick it from recently used/favourites.Regarding the other point, I agree that character literals would be handy, but again I’m not sure if apostrophe is the right character to indicate it. Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT SINGLE QUOTATION MARK would be better, they can be relatively easily typed with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.
I'm not entirely convinced that we *need* special Character literals. The type checker is already able to treat a double-quoted string literal as a String, Character, or UnicodeScalar based on context in most places. Wouldn't it be more valuable to fill the gaps, like Charlie Monroe mentioned above, where these work:
let c: Character = "a"
let c = "a" as Characterand this is caught as an error by the compiler:
let c: Character = "ax"
but this slips through and crashes at runtime?
let c = Character("ax")
I wonder what improvements could be made in the compiler to have that last one do something more appropriate than just call Character.init(String), which causes the runtime error.
This particular case doesn't quite relate to the URL literal/regex
discussion, which would require a complex new static evaluation feature.
For this, the compiler *already has* logic
<https://github.com/apple/swift/blob/master/lib/Sema/CSApply.cpp#L1893> to
determine whether a string literal is expressible as a UnicodeScalar, a
Character, or a String; it's just applied differently when you write
`Character("ax")` vs. `"ax" as Character`, presumably because of the way
the type checker resolves the former to be calling the initializer that
takes a String and thus only treats the literal as a String.
In fact, I recall that John McCall raised this exact issue a while back in
the context of integers:
"[swift-evolution] Proposal: 'T(literal)' should construct T using the
appropriate literal protocol if possible"
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019950.html
Wherein the following expression that looks valid traps at runtime because
it tries to convert the literal to an Int first (which is signed and
therefore overflows) before calling the UInt64 initializer:
let x = UInt64(0x8000_0000_0000_0000)
We've gotten a bit off-topic from the original point of this thread, but
this seems like an item that should be revisited soon, especially if it has
ABI consequences. I wonder if John or another core team member can chime in.
···
On Wed, Jan 11, 2017 at 9:53 PM David Sweeris <davesweeris@mac.com> wrote:
On Jan 11, 2017, at 23:12, Tony Allevato <tony.allevato@gmail.com> wrote:
On Wed, Jan 11, 2017 at 6:46 PM Jay Abbott via swift-evolution < > swift-evolution@swift.org> wrote:
As Rob Mayoff pointed out, you can use MODIFIER LETTER PRIME - or PRIME,
DOUBLE PRIME, and TRIPLE PRIME - which makes more sense than an apostrophe.
Now if only there were a keyboard that had a touch-screen at the top which
could be used for typing context-sensitive characters that would otherwise
be difficult to type. So yeah, solution is to make characters easier to
type, not modify the language. If like me you don't have such a keyboard,
you can always use ctrl+⌘+<space> and type ‘PRIME’ to find it, then pick
it from recently used/favourites.Regarding the other point, I agree that character literals would be handy,
but again I’m not sure if apostrophe is the right character to indicate it.
Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT
SINGLE QUOTATION MARK would be better, they can be relatively easily typed
with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes
into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.I'm not entirely convinced that we *need* special Character literals. The
type checker is already able to treat a double-quoted string literal as a
String, Character, or UnicodeScalar based on context in most places.
Wouldn't it be more valuable to fill the gaps, like Charlie Monroe
mentioned above, where these work:let c: Character = "a"
let c = "a" as Characterand this is caught as an error by the compiler:
let c: Character = "ax"
but this slips through and crashes at runtime?
let c = Character("ax")
I wonder what improvements could be made in the compiler to have that last
one do something more appropriate than just call Character.init(String),
which causes the runtime error.This reminds me of the "URL literal" thread. I believe the two ideas were
essentially to add regex support to the compiler, add support for compiler
"validation" of literals through compile-time functions, or both.IIRC, it was decided that both ideas were at least out of scope for phase
1 (I don't recall if this specific issue was brought up as a potential use
case, though... unlike `Character`, `URL` isn't part of the stdlib).- Dave Sweeris
Georgios - the problem with that character is that it's an apostrophe in
Unicode, not a single-quote. It was originally overloaded as both in ASCII
though hence commonly used as either, especially in programming languages.
I'm definitely with Ted Clancy on this one:
I generally don't care what characters my editor/email client/browser/etc.
use when I type ' on the keyboard, because a human reader will understand
it, so I just do the quickest/easiest thing. But when I'm writing a TeX
document I take care to use an apostrophe where needed and left/right
single quotation marks where needed. And for coding I'd like to be precise,
specific, unambiguous, and technically correct, so either single or double
quotation marks (or ‹ and ›) would be acceptable for character literals. If
compiler can cope with double quotes for both string and character literals
in an unambiguous way then that's fine too.
···
On Thu, 12 Jan 2017 at 14:35 Georgios Moschovitis < george.moschovitis@icloud.com> wrote:
So yeah, solution is to make characters easier to type, not modify the
language.+1
If like me you don't have such a keyboard, you can always use ctrl+⌘+
<space> and type ‘PRIME’ to find it, then pick it from recently
used/favourites.Regarding the other point, I agree that character literals would be handy,
but again I’m not sure if apostrophe is the right character to indicate it.
Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT
SINGLE QUOTATION MARK would be better, they can be relatively easily typed
with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes
into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.I think the single (ASCII) quote is standard enough for use as a character
delimiter.
Interesting background, I wasn’t aware of that.
George.
So yeah, solution is to make characters easier to type, not modify the
language.
+1 to that: what about having editors which provide a graphical access to
such characters just as LaTeX editors give access to maths symbols and some
functions? The equation editors of other softwares (e.g. recent MS Word
version) also have quite usable way to provide such functionalities
-1 on the original proposal itself otherwise (sorry)
I don't think that ' is a character to consider for identifiers. I see
basically two options for such a character:
1) as delimiter (which is what is the most spread use of it, I think, in
programming languages)
2) as an operator
Actually both options might not be mutually exclusive: for instance MATLAB
uses ' both as string delimiter and as transpose postfix operator.
I would personally see the benefit of using ' as operator and could imagine
(in addition to the aforementioned MATLAB use of the postfix operator to
transpose / conjugate transpose matrices) using it as differentiation
operator on pure functions with respect to their input variables. It could
be using options to automatically make finite difference based
differentiation of any function or closure but I could even imagine it
combined with an automatic differentiation scheme at compile-time! This
would be such a great addition to a language with functional programming
capabilities for scientists and engineers.
I admit that these are heavily math/science-oriented uses, but why not?
I can't think of any wide-spread use of ' as prefix or infix operator in
other languages.
Nicolas
···
On Fri, Jan 13, 2017 at 6:28 PM, Georgios Moschovitis via swift-evolution < swift-evolution@swift.org> wrote:
Interesting background, I wasn’t aware of that.
George.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution