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 wrote:
>
> On Apr 22, 2016, at 12:54 PM, Patrick
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
no
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
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
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
>
> * 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 col
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,
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
> wrote:
>
>
> Le 2 avr. 2016 à 15:
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
> 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/g
> 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
>
> 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 lib
>
> * 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
> 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
>
>
> * 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?
Redund
https://doc.perl6.org/language/quoting
> On Mar 24, 2016, at 9:23 AM, Patrick Gili
> wrote:
>
> 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-evolut
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
-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
> mailto:swift-evolution@swift.org>> wrote:
>
&
>
> • 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 w
>
> • 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 o
> 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
Hi Ted,
I don't think many of us that are active on this mailing list had the
opportunity to provide feedback on this proposal review. I very much agree with
you on many points that you bring up below. I have spent a lot of time
scratching my head wondering why it was so important to remove cer
>
> What is your evaluation of the proposal?
This is a well thought out proposal with many facets to simplify importing C
libraries into Swift. I especially like the automatic inference heuristics.
> Is the problem being addressed significant enough to warrant a change to
> Swift?
Yes.
> Does
>
> • 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
Just finished reading your write-up. It sounds similar to the Forwardable
module supported by the Ruby standard library
(http://ruby-doc.org/stdlib-2.0.0/libdoc/forwardable/rdoc/Forwardable.html). Is
this the case?
Cheers,
-Patrick Gili
___
swift-evol
I have to agree with everything Ilya has mentioned in her response.
It comes down to readability. Omit the "return" keyword from a function and
points that the function returns become hard to see. The optional "return"
keyboard in Ruby is one of the few features of Ruby that I genuinely dislike
I would not like to see braces made optional. First, I think this reduces the
readability of the code. While readability might be somewhat subjective,
compare these two blocks of code:
// With braces // Without braces
for i in 0..<10 { for i in 0..<10
for j in 0..<5 {
27 matches
Mail list logo
