Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

2017-11-23 Thread Kelvin Ma via swift-evolution
On Thu, Nov 23, 2017 at 7:08 PM, Xiaodi Wu wrote: > > On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: >> >>> >>> a good idea on paper, a disastrous

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

2017-11-23 Thread Xiaodi Wu via swift-evolution
On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution < swift-evolution@swift.org> wrote: > > > On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: > >> >> a good idea on paper, a disastrous one in practice. What happens if every >> geometry library declares their own Point

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Chris Lattner via swift-evolution
On Nov 23, 2017, at 10:35 AM, Xiaodi Wu via swift-evolution wrote: > This proposed addition addresses a known pain point, to be sure, but I think > it has many implications for the future direction of the language and I'd > like to explore them here. Thanks for

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Kelvin Ma via swift-evolution
aren’t all literals evaluated at compile time? On Thu, Nov 23, 2017 at 6:07 PM, Tony Allevato wrote: > This could be solved by extending the existing string literal handling and > letting type inference do the rest. The real problem here is that > `UInt8(ascii: X)` is

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Chris Lattner via swift-evolution
> On Nov 23, 2017, at 3:07 PM, Tony Allevato via swift-evolution > wrote: > > This could be solved by extending the existing string literal handling and > letting type inference do the rest. The real problem here is that > `UInt8(ascii: X)` is annoying to write

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Tony Allevato via swift-evolution
This could be solved by extending the existing string literal handling and letting type inference do the rest. The real problem here is that `UInt8(ascii: X)` is annoying to write when you're dealing with a large amount of low-level data. If UInt8 conformed to ExpressibleByUnicodeScalarLiteral,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

2017-11-23 Thread Kelvin Ma via swift-evolution
On Thu, Nov 23, 2017 at 5:45 PM, Kelvin Ma wrote: > > > On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: > >> >> a good idea on paper, a disastrous one in practice. What happens if every >> geometry library declares their own Point type? >> >> That would be

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

2017-11-23 Thread Kelvin Ma via swift-evolution
On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: > > a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? > > That would be ugly („disastrous“ imho is a little bit to strong — C++ > had/has similar issues, and

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Kelvin Ma via swift-evolution
On Thu, Nov 23, 2017 at 3:47 PM, Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > > > On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution < >>

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Chris Lattner via swift-evolution
> On Nov 23, 2017, at 11:10 AM, Brent Royal-Gordon > wrote: > > On Nov 23, 2017, at 11:15 AM, Chris Lattner via swift-evolution > > wrote: > >> Until we figure out that path forward for regex’s, I think

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Xiaodi Wu via swift-evolution
On Thu, Nov 23, 2017 at 2:47 PM, Tony Allevato wrote: > > > On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution < >> swift-evolution@swift.org>

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Tony Allevato via swift-evolution
On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution < > swift-evolution@swift.org> wrote: > >> I’m beginning to wish I hadn’t tied this proposal so strongly to regular >>

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Xiaodi Wu via swift-evolution
On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution < swift-evolution@swift.org> wrote: > I’m beginning to wish I hadn’t tied this proposal so strongly to regular > expressions! > It is indeed the wrong motivation. Even as a ten year veteran of Perl > development > I’m not sure

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread John Holdsworth via swift-evolution
I’m beginning to wish I hadn’t tied this proposal so strongly to regular expressions! It is indeed the wrong motivation. Even as a ten year veteran of Perl development I’m not sure we want to bake it into the language quite so tightly (isn’t a part of Foundation?) What would /regex/ represent -

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Xiaodi Wu via swift-evolution
On Thu, Nov 23, 2017 at 1:12 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > On Nov 23, 2017, at 11:15 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > Until we figure out that path forward for regex’s, I think they aren’t the >

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Daniel Duan via swift-evolution
I eh, literally just ran into a situation where this feature would have been super useful: Someone sent me a JSON string with “\” in it. I needed to plug it into the UI logic to test something but I had to escape the “\”s again to make JSONSerialization happy. A raw string literal syntax,

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Brent Royal-Gordon via swift-evolution
> On Nov 23, 2017, at 11:15 AM, Chris Lattner via swift-evolution > wrote: > > Until we figure out that path forward for regex’s, I think they aren’t the > right motivation for this proposal. 1. Even in our shining pattern matching future—a future which I, for one,

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Xiaodi Wu via swift-evolution
This proposed addition addresses a known pain point, to be sure, but I think it has many implications for the future direction of the language and I'd like to explore them here. The tl;dr version is that I'm not sure this is the right direction in which to head to address the issue of regex

Re: [swift-evolution] [Pitch #2] Introduce user-defined dynamically "callable" types

2017-11-23 Thread Ben Rimmington via swift-evolution
DynamicCallable.md DynamicMemberLookup.md JavaScriptCore.JSValue If the JSValue class

Re: [swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread Chris Lattner via swift-evolution
> On Nov 23, 2017, at 9:43 AM, John Holdsworth via swift-evolution > wrote: > > Hello S/E, > > I’d like to put forward a perhaps rather banal change to the Swift lexer > primarily intended to make entering regular expression patterns easier. > >

[swift-evolution] [Pitch] Raw mode string literals

2017-11-23 Thread John Holdsworth via swift-evolution
Hello S/E, I’d like to put forward a perhaps rather banal change to the Swift lexer primarily intended to make entering regular expression patterns easier. https://github.com/DoubleSpeak/swift-evolution/blob/master/proposals/-raw-string-escaping.md

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

2017-11-23 Thread Tino Heth via swift-evolution
> a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? That would be ugly („disastrous“ imho is a little bit to strong — C++ had/has similar issues, and other languages as well) But if there would be a simple Point struct in