[swift-evolution] [Idea] Trailing Multi-Line String Literal

Good day, swift evolution community! I'll just get right to it... Did anyone else beside me wished this was a thing? func parse(allowSomeBehavior: Bool = true, source: String) { // ... } parse(allowSomeBehavior: false) """ This is a source string that contains a number o

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

Personally, I have never felt that need. Trailing closures fill of need of making Swift a good candidate for building DSLs, where they make the function calls look more like first-class operations. But I don’t think that trailing strings would be as useful. David. > On 15 Jun 2017, at 11:54, G

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

Funny you should mention DSLs: let myQuery = sql """ SELECT id, name, date FROM MyTable WHERE id > 100 """ let myLayout = NSLayoutConstraint """ ... """ let myPredicate = NSPredicate "" ... """ > On Jun 15, 2017, at 2:05 PM, David

Re: [swift-evolution] Revisiting SE-0110

Sent from my iPad > On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: >> >> What’s the status of this Chris’s double parens idea below? It garnered some >> positive responses, but the discussion seems to have

Re: [swift-evolution] Revisiting SE-0110

> One (tangential) thing that came up is that tuple element names in tuple > *patterns* should probably be deprecated and removed at some point. Without > looking, what variables does this declare?: > > let (a : Int, b : Float) = foo() I think it would be better if the compiler raised a war

Re: [swift-evolution] Revisiting SE-0110

On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote: > > One (tangential) thing that came up is that tuple element names in tuple > *patterns* should probably be deprecated and removed at some point. > Without looking, what variables does this declar

Re: [swift-evolution] Revisiting SE-0110

Let me clarify: I'm only talking about removing tuple element names from the *pattern* grammar. They would still be allowed on tuple types, which is what you are using. -Chris > On Jun 14, 2017, at 9:45 PM, Charlie Monroe wrote: > > >> On Jun 15, 2017, at 6:01 AM, Chris Lattner via swift-ev

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

I totally see what you are driving at. But I just see less value in it that with trailing closure. But it’s very personal. > On 15 Jun 2017, at 13:18, Gor Gyolchanyan wrote: > > Funny you should mention DSLs: > > let myQuery = sql """ > SELECT id, name, date > FROM MyTable >

Re: [swift-evolution] Revisiting SE-0110

> On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > One (tangential) thing that came up is that tuple element names in tuple > > *patterns* should probably be de

Re: [swift-evolution] Revisiting SE-0110

On Thu, Jun 15, 2017 at 11:19 David Hart wrote: > On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution < > swift-evolution@swift.org> wrote: > >> > One (tangential) thing that came up is

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

Agree with David on all points. Neat idea, but not convinced it’s a win in terms of tidying up code vs. increased burden of new grammar rule. Agree also that it’s a subjective opinion. For me, ({[]}) nesting is clunky both to read and write, but (“”) just doesn’t have the same issues even with mul

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 8:23 AM, Robert Bennett via swift-evolution > wrote: > >> One (tangential) thing that came up is that tuple element names in tuple >> *patterns* should probably be deprecated and removed at some point. Without >> looking, what variables does this declare?: >> >> let (

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 10:28 AM, Chris Lattner wrote: > > >> Is the feature harmful? > > Yes, absolutely. The shadowing isn't the thing that bothers me, it is that > swift has a meaning for that very syntax in other contexts, and that this is > completely different meaning. People absolutel

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 14, 2017, at 4:45 AM, Jérémie Girault > wrote: > @john, the proposal is the fruit of my imagination and the goal was to > discuss about it. > I’m vastly open to change it with the help of anyone if it can be implemented > in a simple way and leads to better compatibility or syntactical

Re: [swift-evolution] Revisiting SE-0110

> > On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution > o > > let (a : Int, b : Float) = foo() I think it would be better if the compiler raised a warning whenever you tried to redefine a builtin type. >>> >>> That’s essentially my preferred solution

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

I too really like this proposal; personally I can attest to how it probably would have saved some time and headache with the Foundation overlay as well as swift-corelibs-foundation (specifically when adopting Collection and friends for types) Would it be reasonable to have this apply to typeali

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

I agree that nested braces in parentheses are much more ugly then nested quotes in parentheses. About ExressibleByStringLiteral: This is a completely orthogonal case. The issue is passing these string literals to functions. The passed literal doesn't have to be string, it can be any other Expres

Re: [swift-evolution] Revisiting SE-0110

Yes, in the sense that the grammar has a production that permits the tuple element name. But there aren't any examples that use labels w

Re: [swift-evolution] Revisiting SE-0110

It’s not just a syntactic thing we’re talking about here. The grammar permits all kinds of wonky combinations of things that will parse as “TSPL Swift", but will fail in Sema. In that sense, no, this feature is not documented there. ~Robert Widmann > On Jun 15, 2017, at 12:08 PM, Kyle Murray

Re: [swift-evolution] Revisiting SE-0110

> On 15 Jun 2017, at 19:28, Chris Lattner wrote: > > > On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution > mailto:swift-evolution@swift.org>> o >>> > >>> > let (a : Int, b : Float) = foo() >>> >>> >>> I think it would be better if the compiler raised a warning whenever you >>> tr

Re: [swift-evolution] Revisiting SE-0110

> On 16 Jun 2017, at 00:41, David Hart wrote: > > >> On 15 Jun 2017, at 19:28, Chris Lattner > > wrote: >> >> >> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> o > > let (a : Int, b : Float) = foo()

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 10:28 AM, Chris Lattner via swift-evolution > wrote: > > My belief on this is that it is a legacy Swift 1 type system capability that > no one uses. I have no data to show that though. Tangential and perhaps a terrible idea, but: It's 2017. Can we instrument the compil

Re: [swift-evolution] Revisiting SE-0110

On Thu, Jun 15, 2017 at 17:43 David Hart wrote: > On 16 Jun 2017, at 00:41, David Hart wrote: > > > On 15 Jun 2017, at 19:28, Chris Lattner wrote: > > > On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> o > > > >>> > let (a : Int, b : Float) = foo() >>>

Re: [swift-evolution] Revisiting SE-0110

On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart wrote: On 16 Jun 2017, at 00:41, David Hart wrote: On 15 Jun 2017, at 19:28, Chris Lattner wrote: On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift

Re: [swift-evolution] Revisiting SE-0110

> On 15 Jun 2017, at 06:01, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: >> >> What’s the status of this Chris’s double parens idea below? It garnered some >> positive responses, but the discussion seems to have fizzled out. Is there >

Re: [swift-evolution] Revisiting SE-0110

On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel wrote: > On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart wrote: > >> On 16 Jun 2017, at 00:41, David Hart wrote: >> >> >> On 15 Jun 2017, at 19:28, Chris Latt

Re: [swift-evolution] Revisiting SE-0110

> On 16 Jun 2017, at 01:55, Xiaodi Wu wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart wrote: On 16 Jun 2017, at 00:41, David Hart wrote: On 15 Jun 2017, at 19:28, Chris Lattner wrote: On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution

Re: [swift-evolution] Revisiting SE-0110

On Fri, Jun 16, 2017 at 12:17 AM, David Hart wrote: > > > On 16 Jun 2017, at 01:55, Xiaodi Wu wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart wrote: > >> On 16 Jun 2017, at 00:41, David Hart wrote: >> >> >> On 15 Jun 2017, at 19:28, Chris Lattner wrote: >> >> >> On Jun 15, 2017, at 9:41 A

Re: [swift-evolution] Revisiting SE-0110

It seems to me that we have a general problem with labels and every time we have to push things around they break and we simply rip them out: first with argument labels in closures and stores functions (sigh... :/, but we may get labels back somehow there one day not too far from now hopefully)

Re: [swift-evolution] Revisiting SE-0110

> On 16 Jun 2017, at 08:04, Xiaodi Wu wrote: > >> On Fri, Jun 16, 2017 at 12:17 AM, David Hart wrote: >> >> >>> On 16 Jun 2017, at 01:55, Xiaodi Wu wrote: >>> >>> On Thu, Jun 15, 2017 at 17:43 David Hart wrote: >> On 16 Jun 2017, at 00:41, David Hart wrote: >> >> >> On 1