Re: [swift-evolution] multi-line string literals.

[Patrick Gili via swift-evolution]

My thinking here was two-fold:
1) Address the need to accommodate the lack of regex literals today, and
2) Future-proof the proposal to accommodate the eventuality of regex literals.

-Patrick

> On Apr 24, 2016, at 6:09 PM, Chris Lattner <clatt...@apple.com> wrote:
> 
> On Apr 22, 2016, at 12:54 PM, Patrick Gili via swift-evolution 
> <swift-evolution@swift.org> wrote:
>> If we use a quoting structure similar to Perl6, then we future proof the 
>> grammar to accommodate regular expression literals (and multi-line regular 
>> expression literals) later. It also gives us the possibility for support for 
>> fine-grain control over escaping and interpolation.
> 
> Wouldn’t the natural regex literal syntax be to enclose them in /’s, e.g.  
> /foo*/  ?
> 
> I don’t see how this proposal conflicts with that.
> 
> -Chris
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] multi-line string literals.

[Patrick Gili via swift-evolution]

This is oversimplifying the problem of escaping. Simply relaxing the grammar 
for the content of the string literal doesn't always work.

For example, a regular expression that detects a might be written "\N*\n". If 
escaping is enabled, then the compiler changes "\n" into line feed, which does 
not have the same meaning to the regular expression engine as "\n".

-Patrick

> On Apr 22, 2016, at 11:13 PM, John Holdsworth  wrote:
> 
> Regex support certainly needs to be kept in mind. I can propose something a 
> little different
> on that front however that retains the existing simple literal syntax. Bear 
> with me.
> 
> What if invalid escape sequences did not result in an error but were passed 
> through to the string?
> This is a very small change to the lexer.
> 
> For example:
> 
>> print( “\w+[\w\d]+” )
> \w+[\w\d]+
> 
> It’s easy for a developer to know there are only seven valid escapes \0, \r, 
> \n, \”, \’, \\  and \u{}
> so the error is not a particularly helpful one and these escapes do not 
> overlap with regex syntax.
> 
> In this way you get the best of both worlds, minimalist string syntax and not 
> have to write “\\w+[\\w\\d]+”
> 
> John
> 
>> On 22 Apr 2016, at 20:54, Patrick Gili  wrote:
>> 
>> If we use a quoting structure similar to Perl6, then we future proof the 
>> grammar to accommodate regular expression literals (and multi-line regular 
>> expression literals) later. It also gives us the possibility for support for 
>> fine-grain control over escaping and interpolation.
>> 
>> -Patrick
>> 
>>> On Apr 22, 2016, at 2:48 PM, John Holdsworth  
>>> wrote:
>>> 
>>> As a long time user of Perl, for me the simplicity and lack of flexibility 
>>> is the attraction
>>> when it comes to “”” syntax ;) That’s a lot of documentation for just 
>>> specifying a string.
>>> 
>>> Perl makes life difficult for itself due to it’s rather simplistic $var 
>>> interpolation syntax
>>> which means you frequently want an un-interpolated string literal. The 
>>> situation is
>>> far better in Swift with the more distinct \().
>>> 
>>> Can you think of anything that couldn’t be readily expressed using Python 
>>> style “””?
>>> 
>>> John
 On 22 Apr 2016, at 19:12, Patrick Gili  
 wrote:
 
 This doesn't provide very much flexibility. I'd like to see something more 
 like Perl6's quoting constructs: https://doc.perl6.org/language/quoting.
 
 -Patrick
 
> On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution 
>  wrote:
> 
> I’ve raised a speculative PR against the Swift Lexer to support 
> multi-line string literals as was
> suggested in the very first week Swift was open sourced and before that 
> in various radars.
> 
> https://github.com/apple/swift/pull/2275
> 
> The approach taken is as simple as possible defining multi-line strings 
> as being
> delimited by “”” instead of “ and thereafter able to contain new line 
> characters.
> 
> There has been some discussion of this before on swift-evolution:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html
> 
> I’m trying to avoid more advanced features such as the handling of 
> indenting which
> for me complicates something that if kept simple can be documented very 
> easily.
> 
> This change will require a evolution proposal so I’d like to take the 
> pulse before I write it up.
> 
> Thoughts?
> 
> John
> ___
> 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

Re: [swift-evolution] multi-line string literals.

[Patrick Gili via swift-evolution]

If we use a quoting structure similar to Perl6, then we future proof the 
grammar to accommodate regular expression literals (and multi-line regular 
expression literals) later. It also gives us the possibility for support for 
fine-grain control over escaping and interpolation.

-Patrick

> On Apr 22, 2016, at 2:48 PM, John Holdsworth  wrote:
> 
> As a long time user of Perl, for me the simplicity and lack of flexibility is 
> the attraction
> when it comes to “”” syntax ;) That’s a lot of documentation for just 
> specifying a string.
> 
> Perl makes life difficult for itself due to it’s rather simplistic $var 
> interpolation syntax
> which means you frequently want an un-interpolated string literal. The 
> situation is
> far better in Swift with the more distinct \().
> 
> Can you think of anything that couldn’t be readily expressed using Python 
> style “””?
> 
> John
>> On 22 Apr 2016, at 19:12, Patrick Gili  wrote:
>> 
>> This doesn't provide very much flexibility. I'd like to see something more 
>> like Perl6's quoting constructs: https://doc.perl6.org/language/quoting.
>> 
>> -Patrick
>> 
>>> On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution 
>>>  wrote:
>>> 
>>> I’ve raised a speculative PR against the Swift Lexer to support multi-line 
>>> string literals as was
>>> suggested in the very first week Swift was open sourced and before that in 
>>> various radars.
>>> 
>>> https://github.com/apple/swift/pull/2275
>>> 
>>> The approach taken is as simple as possible defining multi-line strings as 
>>> being
>>> delimited by “”” instead of “ and thereafter able to contain new line 
>>> characters.
>>> 
>>> There has been some discussion of this before on swift-evolution:
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html
>>> 
>>> I’m trying to avoid more advanced features such as the handling of 
>>> indenting which
>>> for me complicates something that if kept simple can be documented very 
>>> easily.
>>> 
>>> This change will require a evolution proposal so I’d like to take the pulse 
>>> before I write it up.
>>> 
>>> Thoughts?
>>> 
>>> John
>>> ___
>>> 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

Re: [swift-evolution] multi-line string literals.

[Patrick Gili via swift-evolution]

This doesn't provide very much flexibility. I'd like to see something more like 
Perl6's quoting constructs: https://doc.perl6.org/language/quoting.

-Patrick

> On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution 
>  wrote:
> 
> I’ve raised a speculative PR against the Swift Lexer to support multi-line 
> string literals as was
> suggested in the very first week Swift was open sourced and before that in 
> various radars.
> 
> https://github.com/apple/swift/pull/2275
> 
> The approach taken is as simple as possible defining multi-line strings as 
> being
> delimited by “”” instead of “ and thereafter able to contain new line 
> characters.
> 
> There has been some discussion of this before on swift-evolution:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html
> 
> I’m trying to avoid more advanced features such as the handling of indenting 
> which
> for me complicates something that if kept simple can be documented very 
> easily.
> 
> This change will require a evolution proposal so I’d like to take the pulse 
> before I write it up.
> 
> Thoughts?
> 
> John
> ___
> 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

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

[Patrick Gili via swift-evolution]

I have to agree with those that simply want enumerate() fixed. There are many 
modern languages that have a similar function, such as Ruby.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Patrick Gili via swift-evolution]

> 
>   * What is your evaluation of the proposal?

1) I think eliminating intervals increases consistency and reduces confusion.

2) I really like the fact that this will make in-place index traversal methods 
public. It will reduce the amount of boilerplate for developers implementing 
new collections.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Most modern languages provide a sophisticated library supporting collections. I 
think this proposal is moving the Swift Foundation in the direction of the C++ 
STL and Boost libraries.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

In-depth.

> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Patrick Gili via swift-evolution]

As an alternative, could we require the parens on the return. For example:

(Int) -> (Float)
(String) -> ()
() -> ()
() -> (Double)

This looks cleaner, improves consistency, and simplifies the syntax (i.e., no 
need to remember when parens are necessary).

-Patrick

> On Apr 15, 2016, at 1:38 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Apr 15, 2016, at 5:11 AM, David Hart  wrote:
>> 
>> If the original rationale is gone, shouldn’t we also get rid of the empty 
>> tuple-type and replace it by a full-blown Void instead of Void being a 
>> typealis for the empty tuple?
> 
> This could be done, but it would make the language larger and less 
> consistent.  It would require introducing a new concept (a first class Void 
> type).  Further, at some point we may have the ability to define algorithms 
> over arbitrary width tuples (e.g. perhaps like C++ variadic templates) and 
> that benefits from having the empty tuple as a base case.
> 
> -Chris
> 
> 
>> (Int) -> Float
>> (String) -> Void
>> () -> Void
>> () -> Double
>> 
>> It looks more consistent to me.
>> 
>>> On 15 Apr 2016, at 06:57, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> We currently accept function type syntax without parentheses, like:
>>> 
>>> Int -> Float
>>> String -> ()
>>> 
>>> etc.  The original rationale aligned with the fact that we wanted to treat 
>>> all functions as taking a single parameter (which was often of tuple type) 
>>> and producing a tuple value (which was sometimes a tuple, in the case of 
>>> void and multiple return values).  However, we’ve long since moved on from 
>>> that early design point: there are a number of things that you can only do 
>>> in a parameter list now (varargs, default args, etc), implicit tuple splat 
>>> has been removed, and  the compiler has long ago stopped modeling function 
>>> parameters this way.  Beyond that, it eliminates one potential style war.
>>> 
>>> Given all this, I think it makes sense to go for syntactic uniformity 
>>> between parameter list and function types, and just require parenthesis on 
>>> the argument list.  The types above can be trivially written as:
>>> 
>>> (Int) -> Float
>>> (String) -> ()
>>> 
>>> Thoughts?
>>> 
>>> -Chris
>>> ___
>>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Patrick Gili via swift-evolution]

If I understand you correctly, you think adding keywords represents an 
inconsistency. However, I think it would add considerable consistency and 
utility to the Swift language. Yes, it would make it inconsistent with the 
generations of C-like languages that have come before it. However, I think 
we've already taken considerable steps from away from C-like languages; for 
example, removing C-like for-loop syntax and unary increment/decrement 
operators.

-Patrick

> On Apr 3, 2016, at 11:44 AM, Dany St-Amant via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
> 
>>> What is your evaluation of the proposal?
>> I think there is a lot of value to allowing trailing closures in the guard 
>> condition clause. However, not at the cost of inconsistency. We have 
>> reviewed many proposals over the last month that addressed consistency 
>> issues in the Swift language, and if I'm not mistaken, all of them have been 
>> accepted by the community, larger to eliminate the inconsistency.
>> 
>> Because of this, I think two of the alternatives stated by the proposal have 
>> credibility:
>> 1) Eliminate the "else" keyword from the guard syntax.
>> 2) Add keywords to "if", "while", "for", and "switch" to delineate the 
>> condition clause from the body of the statement.
>> 
>> The second alternative has more appeal, because it supports trailing 
>> closures without "heroics".
> 
> It have been mentioned multiple times that allowing trailing closure only for 
> guard is creating an inconsistency, but these keywords already are 
> inconsistent with the each other (beside the presence of the 'trailing' else 
> keyword) on the variable scoping:
> 
> - guard let: outer scope immutable variable
> - if let: inner scope immutable variable
> - for: inner scope immutable variable without let keyword
> 
> Consistency is good, but since each keywords are not for the exact same 
> thing, it is normal to see some variances.  Like the global scope of the 
> immutable variable created by guard; as per the intent of the keyword, or its 
> trailing else keyword; needed to clarify that what follow is for, for lack of 
> better word, the 'else' case.
> 
> So as long as such inconsistency have a "raison d'être", that they have been 
> designed and are not an oversight; there should be no reason to not allow 
> them.
> 
> Dany
> 
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> No.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> No. Please don't add inconsistencies to the language, as we're just going to 
>> have to deal with it down the road.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> Not in my experience.
>> 
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>> 
>> In-depth study.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Patrick Gili via swift-evolution]

Personally, I don't like any of the options. However, I mentioned this during 
the review of the API naming guidelines. Using the English language to 
construct function names that distinguish between functional and imperative 
forms of the operation places constraints on API designers that produce 
undesirable results. The operations on an algebraic set is merely one example. 
My preference is a symbol appended to the function name (e.g., the exclamation 
point in Ruby). However, it was pointed out at the time that introducing this 
syntax was out-of-scope for Swift 3. What does this mean? We'll revisit this 
later and have to endure the rigor of another API renaming exercise?

Without rehashing the utility of a symbol to distinguish between functional and 
imperative, what is my preference?

Pseudo-verbs? I don't know if this is any better.

A suffix, such as "InPlace", has some appeal for two reasons:

1) It is descriptive and doesn't obfuscate the meaning of the operation.

2) If at sometime later the community sees a practical need to introduce syntax 
to distinguish between functional and imperative forms of an operation, 
removing such a suffix and replacing it with the symbol will mitigate confusion 
of another renaming transition.

Cheers,
-Patrick

> On Apr 2, 2016, at 5:15 PM, Brent Royal-Gordon  wrote:
> 
>> For example, changing union() to formUnion() for the sake of aligning 
>> compliance to API name guidelines simply doesn't make sense to me.
> 
> Given the need for separate names for the functional and imperative forms of 
> this operation, what sorts of names would be better? Pseudo-verbs like 
> `unioning`? An `InPlace` suffix?
> 
> (Everyone else, please don't take this as an invitation to start the 
> bikeshedding again. I'm trying to understand what *this reviewer* prefers.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Patrick Gili via swift-evolution]

> What is your evaluation of the proposal?
I am strongly opposed to the changes to the names of functions implementing set 
operations, as it is going to introduce a lot of confusion. While I'm a fairly 
rigid about consistency, I do think that there are acceptable exceptions to any 
set of rules/guidelines. This represents one of those cases. For example, 
changing union() to formUnion() for the sake of aligning compliance to API name 
guidelines simply doesn't make sense to me.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
No.

> Does this proposal fit well with the feel and direction of Swift?
No.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
There are plenty of other languages that have API naming guidelines, such as 
C#, Ruby, and Python. However, they all demonstrate enough lenience to 
accommodate cases such as this. For example, 
http://ruby-doc.org/stdlib-2.3.0/libdoc/set/rdoc/Set.html.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

In-depth.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Patrick Gili via swift-evolution]

> What is your evaluation of the proposal?
I think there is a lot of value to allowing trailing closures in the guard 
condition clause. However, not at the cost of inconsistency. We have reviewed 
many proposals over the last month that addressed consistency issues in the 
Swift language, and if I'm not mistaken, all of them have been accepted by the 
community, larger to eliminate the inconsistency.

Because of this, I think two of the alternatives stated by the proposal have 
credibility:
1) Eliminate the "else" keyword from the guard syntax.
2) Add keywords to "if", "while", "for", and "switch" to delineate the 
condition clause from the body of the statement.

The second alternative has more appeal, because it supports trailing closures 
without "heroics".

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
No.

> Does this proposal fit well with the feel and direction of Swift?
No. Please don't add inconsistencies to the language, as we're just going to 
have to deal with it down the road.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Not in my experience.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

In-depth study.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Patrick Gili via swift-evolution]

> 
> What is your evaluation of the proposal?
Anything that increases consistency is good.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes.

> Does this proposal fit well with the feel and direction of Swift?
Yes.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
n/a

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Quick read.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Patrick Gili via swift-evolution]

> 
>   * What is your evaluation of the proposal?

The IUO is not a transitional technology, as it is essential to bridge from 
languages from which Swift evolved, such as C and Objective-C. The proposal 
doesn't give much consideration to this application of IUOs, and hence, I 
cannot support the proposal in its current state.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Grant it, the use of IUO outside of bridging is strange and probably a poor 
practice. However, there seems to exist a requirement and this proposal would 
make satisfying this requirement more difficult.

>   * Does this proposal fit well with the feel and direction of Swift?

No.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Not applicable.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

In-depth study.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0048: Generic Type Aliases

[Patrick Gili via swift-evolution]

> What is your evaluation of the proposal?
+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes.

> Does this proposal fit well with the feel and direction of Swift?

Yes.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I have not used a language with a similar feature.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Read thoroughly.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

[Patrick Gili via swift-evolution]

> 
> 
>   * What is your evaluation of the proposal?

Given var has been removed and inout has been moved, forcing developers to 
specify let seems redundant, and hence I support the proposal.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Redundancy is as bad as inconsistency. Hence, the problem is significant enough 
to warrant a change.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Not really.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick read.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Alternate proposal for multi-line string literial

[Patrick Gili via swift-evolution]

I'm more in favor of Perl6 stye string literals, in general.

-Patrick

> On Mar 23, 2016, at 12:49 AM, Steve K. Chiu via swift-evolution 
>  wrote:
> 
> Hi,
> 
> I am new to swift-evolution list, here is my draft proposal for the 
> multi-line string literal problem.
> The idea had been discussed in the list before, but it seems there are no 
> real solution to many of the string literal problem.
> Let's first define what are the problem with string literal:
> 
> 1. should be able to disable escape char
> 
> 2. or better, able to replace escape char with user defined char
> 
> 3. should be able to write multi-line string literal, and is copy-paste 
> friendly
> 
> 4. for multi-line string, should be  able to remove first and last newline 
> char, so user can write string in block
> 
> 5. for multi-line string, should be  able to remove leading indent, or remove 
> all indent
> 
> 6. for multi-line string, should be  able to replace newline with user 
> defined string ("\r\n", "\r", "\r", or simply " ")
> 
> 7. should be able to add feature over time, without breaking existing code
> 
> My proposal to the above problem is to introduce new 'process instruction' 
> (not sure how to call it), in the following form:
> 
> #string(options) "text"
> 
> for example:
> 
> #string(escape: nil) "^\d+"
> 
> #string(escape: "$", end: "") "
>$(username),
>Is it 1358 yet?
> "
> 
> It is possible to add many options list above, and you can add more options 
> over time without breaking code.
> 
> #string(
> escape: Character? = "\\",
> end: String? = nil,   
> skipEnclosureNewline: Bool = true,
> skipLeadingIndent: Bool = true, 
> skipAllIndent: Bool = false,
> newline: String? = nil
> )
> 
> for 1. & 2., escape option to replace escape char, pass nil will disable 
> escape.
> 
> for 3., end option for end-of-string mark, pass nil will disable multi-line 
> processing.
> 
> for 4., skipEnclosureNewline will skip newline if it is the first or last 
> char of the string.
> 
> for 5., skipLeadingIndent will skip leading indent, leading indent is the 
> leading white-spaces of first line of multi-line string.
> 
> for 5., skipAllIndent will skip all indent, this will override 
> skipLeadingIndent.
> 
> for 6., newline option to replace newline char in multi-line string, pass nil 
> will disable the replacement (as-is in the source).
> 
> But there are one problem remain, as you can see, the #string with options 
> will become very long; I don't think it is a pleasure to use such expression 
> except for one time literal. To fix the problem, I propose yet another 
> process instruction:
> 
> #let #rex = #string(escape: nil)
> #let #mail = #string(escape: "$", end: "")
> 
> Now you can write the string as:
> 
> #rex "^\d+"
> 
> #mail "
>$(username),
>Is it 1358 yet?
> "
> 
> #let should be able to be used with other # process instruction as well, for 
> example, #available, among other things.
> 
> What do you think?
> 
> 
> ___
> 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

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Patrick Gili via swift-evolution]

I understand this. I am looking forward to see what Ted proposes.

-Patrick

> On Mar 19, 2016, at 2:31 PM, Ross O'Brien <narrativium+sw...@gmail.com> wrote:
> 
> But the discussion is no longer about 'do we really need to take this feature 
> out?'. The feature is already out. It's deprecated in Swift 2.2. The 
> discussion is 'is there a compelling reason to put it back in again?'.
> 
> We still have for-in loops. We still have repeat while. We still have 
> forEach. Iteration isn't going anywhere; it just doesn't have this peculiar 
> semi-colon structure any more. It's a confusing structure for beginning 
> programmers to learn in the first place, and Swift doesn't use semi-colons so 
> much.
> 
> On Sat, Mar 19, 2016 at 6:06 PM, Patrick Gili via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen <tedvgios...@gmail.com 
>> <mailto:tedvgios...@gmail.com>> wrote:
>> 
>> On Chris’s advice, I’ve spawned this into a new discussion topic, for which 
>> the base could be
>> part of what I wrote in relation to SE-0007. 
>> 
>> 
>> Hello Patrick
>> as I wrote: 
>> As a result of removing the classical for loop it is to be expected that lot 
>> of people might consider thinking twice about switching to Swift, If they 
>> have to live without (or cumbersome work around) language elements that have 
>> proven to be very useful for at least a few decades...
> 
> There are two groups of people to consider:
> 
> 1) OS X and iOS developers; this group is stuck with whatever the language 
> brings them, for good or bad. If this group of people doesn't like a decision 
> made by the community, they can grumble about it for awhile, suck in a deep 
> breath, and move on.
> 
> 2) Others; this group may be considering using Swift to develop software on 
> other platforms and in other environments. If this group of people doesn't 
> like a decision made by the community, they may think twice and it could 
> significantly impact the uptake by this group of developers. I think it is 
> wise that the community lubricate the transition to Swift as much as possible 
> for this group of developers. I ask if leaving this kind of syntax in the 
> language is so bad? Does it fall in the same category as removing function 
> currying? My gut tells me not, but I could be wrong.
> 
>> 
>> I also find it of the most importance to keep Swift accessible for all kinds 
>> of programmers
>> from starters to academic. 
>> 
>> Graig Federighi said 
>> We think it should be everywhere and used by everyone.
>> 
>> 
>> I subscribe to that.
>> 
>> 
>> -TedvG
>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

[Patrick Gili via swift-evolution]

> 
>   • What is your evaluation of the proposal?

+1

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I really don't like language compilers/interpreters that do not warn when a 
return value hasn't been consumed. It is one of the few aspects of Ruby that I 
dislike, and it causes no end of frustration. However, this enforces a policy 
while allowing a opt-out behavior, which is a plus. Either way, the developer 
was forced to consider the return value.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick read.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

[Patrick Gili via swift-evolution]

> 
>   • What is your evaluation of the proposal?

I think anything that improves pattern matching is a good thing for Swift.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Haskell and ML have very flexible pattern matching capabilities.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
Quick read.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Patrick Gili via swift-evolution]

> On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen  
> wrote:
> 
> On Chris’s advice, I’ve spawned this into a new discussion topic, for which 
> the base could be
> part of what I wrote in relation to SE-0007. 
> 
> 
> Hello Patrick
> as I wrote: 
> As a result of removing the classical for loop it is to be expected that lot 
> of people might consider thinking twice about switching to Swift, If they 
> have to live without (or cumbersome work around) language elements that have 
> proven to be very useful for at least a few decades...

There are two groups of people to consider:

1) OS X and iOS developers; this group is stuck with whatever the language 
brings them, for good or bad. If this group of people doesn't like a decision 
made by the community, they can grumble about it for awhile, suck in a deep 
breath, and move on.

2) Others; this group may be considering using Swift to develop software on 
other platforms and in other environments. If this group of people doesn't like 
a decision made by the community, they may think twice and it could 
significantly impact the uptake by this group of developers. I think it is wise 
that the community lubricate the transition to Swift as much as possible for 
this group of developers. I ask if leaving this kind of syntax in the language 
is so bad? Does it fall in the same category as removing function currying? My 
gut tells me not, but I could be wrong.

> 
> I also find it of the most importance to keep Swift accessible for all kinds 
> of programmers
> from starters to academic. 
> 
> Graig Federighi said 
> We think it should be everywhere and used by everyone.
> 
> 
> I subscribe to that.
> 
> 
> -TedvG
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0042 Flattening the function type of unapplied method references

[Patrick Gili via swift-evolution]

> 
>   • What is your evaluation of the proposal?

This is consistent with removing curried functions from Swift, and hence I'm in 
favor of it; consistency is good.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Well, it feels like many modern languages are going the opposite direction; 
that is, incorporating more functional programming. I think Swift's approach is 
more programmatic though.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Read thoroughly.

> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution