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

on Tue Apr 26 2016, Haravikk wrote: > I prefer the index() method name for this purpose, but I wonder if we might > want > to consider overloads for forward/backward, since not all indexes are > bidirectional (or at least, not efficiently so), for example: > >

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

on Sun Apr 24 2016, John Holdsworth wrote: > To audition Xcode using the following multi-line syntax: > > let xml = " > " > " > " \(author) > " XML Developer's Guide > " Computer > " 44.95 > " 2000-10-01 > " An in-depth look at creating applications with > XML. > "

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Tue Apr 26 2016, Tony Allevato wrote: > On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution > wrote: > > > > func isEqual(to other: Self) ->Bool > > > func isLess(than other: Self) ->Bool > > > func

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

Unrelated to this discussion about comparison operators, please remember to put back .abs() or .absoluteValue() somewhere in FloatingPoint. Thanks! On Tue, Apr 26, 2016 at 12:07 PM, Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > If performance is the only reasons to

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

on Fri Apr 22 2016, 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

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

on Mon Apr 25 2016, Xiaodi Wu wrote: > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams > wrote: > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > Quick thought: > > > > Why are you reaching for the "form..." rule for the mutating

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> On Apr 26, 2016, at 1:31 PM, Chris Lattner wrote: > > >> On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution >> > wrote: >> >> What is your evaluation of the proposal? >> I reluctantly agree with

Re: [swift-evolution] Localization support for string interpolation

on Mon Apr 25 2016, Erica Sadun wrote: >> On Apr 25, 2016, at 7:15 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> I believe I also had concerns about this design because it needlessly >>> misses opportunities for compile-time type safety. There

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

Do you actually want a method added, or just conformance to AbsoluteValuable? – Steve > On Apr 26, 2016, at 7:41 PM, Xiaodi Wu wrote: > > Unrelated to this discussion about comparison operators, please remember to > put back .abs() or .absoluteValue() somewhere in

Re: [swift-evolution] swift generics not generic enough?

Thanks for the link. I founded the original HKT mega thread only. Good to know Swift 3.0 is working on complete generics. - baojun On Mon, Apr 25, 2016 at 6:47 PM Daniel Duan via swift-evolution < swift-evolution@swift.org> wrote: > Baojun Wang via swift-evolution writes:

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

Hi Michael also inline > On 26 Apr 2016, at 22:05, Michael Peternell wrote: > > Comments inline. > >> Am 26.04.2016 um 15:32 schrieb Ted F.A. van Gaalen : >> >> Hi Michael >> >> What happens if a delimiter in this case: “”” >> occurs

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

> On Apr 26, 2016, at 3:33 AM, James Froggatt wrote: > > Fair enough. Upon reflection, I think my real issue is somewhat different to > what I suggested previously. > > I wasn't intending to suggest such a thing would be practical, just that it > would be a decent

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0072: Fully eliminate implicit bridging conversions from Swift

> The review of "SE-0072: Fully eliminate implicit bridging conversions from > Swift" begins now and runs through May 2. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md The problem with

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> On Apr 26, 2016, at 1:33 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 26, 2016, at 5:56 AM, Vladimir.S via swift-evolution >> wrote: >> >> On 26.04.2016 9:38, Goffredo Marocchi via swift-evolution wrote: >>> >>>

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> On Apr 26, 2016, at 3:07 PM, Michael Peternell via swift-evolution > wrote: > > I can't see that it would create any ambiguities to not use parens. () is also used in type syntax for tuples, so without this requirement, (Int, Int) -> T is ambiguous between having

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

+1 I think it's a good thing. I don't think that it would introduce any bad ambiguities for the human reader. E.g. "case .default:" may look like "default:", but so does "case .`default`:" - all other cases that I can think of don't seem to introduce any problems. > Am 26.04.2016 um 06:20

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> • What is your evaluation of the proposal? -10 strongly against it. I can't see that it would create any ambiguities to not use parens. In all cases, I can see the meaning of a function type, e.g. Int -> String is a function that takes an Int and produces a String; (Int) -> String

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

Fair enough. Upon reflection, I think my real issue is somewhat different to what I suggested previously. I wasn't intending to suggest such a thing would be practical, just that it would be a decent alternative to optional protocol requirements. The alternative given in the proposal seems to

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

> * What is your evaluation of the proposal? +1 The new API conventions for member references (especially enums) seem broken without this proposal IMHO. > * Is the problem being addressed significant enough to warrant a change > to Swift? I think it is paramount. > * Does

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

> On 26 Apr 2016, at 06:20, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "Allow (most) keywords in member references" begins now and > runs through April 29th. The proposal is available here: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0071: Allow (most) keywords in member references

> > * 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? Absolutely. .`default` looks very odd, as if it was some

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> What is your evaluation of the proposal? A somewhat reluctant +1. I like the sugar but Chris makes a good case about the ambiguities and the move away from functional tradition. I am a bit sad about the need for parentheses but it seems like maybe it's for the best. I also must admit

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> On Apr 26, 2016, at 3:30 PM, Joe Groff wrote: > > >> On Apr 26, 2016, at 1:33 PM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On Apr 26, 2016, at 5:56 AM, Vladimir.S via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Apr 26, 2016, at 7:34 PM, Tony Allevato via swift-evolution wrote: > Would something like this be possible? Imagine protocols defined like this: > > public protocol Equatable { > static func == (lhs: Self, rhs: Self) -> Self > } The problem is that every

Re: [swift-evolution] @noescape and nil

> On Apr 26, 2016, at 6:58 PM, Daniel Duan wrote: > > Wouldn't this work in Swift 3 though? > > func testFunc(times: Int, fn: (@noescape (Int)->Void)? = nil) { … } Yes, that got implemented in Swift 3, with a narrow Optional-specific hack :-) -Chris > > Sent from my iPad

Re: [swift-evolution] SE-0066 Reaction

On Apr 26, 2016, at 3:37 PM, Mishal Awadah wrote: > This analogy doesn’t exist in Swift, languages like Haskell have > auto-currying behavior like this, but Swift does not. > > Indeed, my point is that this proposal drives the distance further from this > analogy, which is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

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

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0072: Fully eliminate implicit bridging conversions from Swift

> On Apr 26, 2016, at 2:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> The review of "SE-0072: Fully eliminate implicit bridging conversions from >> Swift" begins now and runs through May 2. The proposal is available here: >> >> >>

Re: [swift-evolution] Localization support for string interpolation

On 22 Apr 2016, at 09:09, Daniel Höpfl via swift-evolution wrote: > On 21.04.16 18:29, Uli Kusterer wrote: >> Yeah, idea here is principle of least surprise. Most lcoalization >> tools pre-populate the translations with the keys, so having the >> positional indices in

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On 2016-04-26 22:32:16 +, Dave Abrahams via swift-evolution said: The main reasons to route through a single generic operator implementation are: * User experience; we want to cut down the number of overloads of any operator to a manageable set, in part because they live in the global

Re: [swift-evolution] Localization support for string interpolation

On 24 Apr 2016, at 23:40, Chris Lattner via swift-evolution wrote: > Int could then implement support for “x” to print hexadecimal, we could > support left/right whitespace padding, and custom types could provide their > own custom formatters (e.g. a string could

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

On 22 Apr 2016, at 18:59, John Holdsworth via swift-evolution wrote: > 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

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

> Just ignore me if that's been covered in the archives already (there is a lot > there, I'm still catching up), but is there a reason we can't just allow > newlines in the existing string constants and be done with it? Since they've > been invalid so far, nobody has code that contains line

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

> Doesn't strike me as a problem needing a solution, though. Strings are > syntax-colored differently than actual code. So if it's really runaway, > you're likely to notice the wrong color. And the likelihood of the code > actually still compiling after grabbing the next random quote to

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

Hi Michael What happens if a delimiter in this case: “”” occurs embedded in the data? like so (two times here): “”” dfksposdkj dslkd s hfdslk dskdslk lskd sk aaasd lfsdlks dslksd sdlk sdlksd “”” fskfsdalkfsd “”” fdjf dkjfds “”" Having a particular token at the start of a line (or

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0067: Enhanced Floating Point Protocols

> isLessThanOrEqual(to:) --> isLessThanOrEqualTo(_:). I'm still not totally > convinced that this is an improvement, so I'd love to hear further > suggestions on how to handle this case. One possibility would be `isNoGreater(than:)`, which neatly sidesteps the problem. However, given the

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPhone On Apr 25, 2016, at 10:03 PM, Brent Royal-Gordon wrote: >> Note that, if we do the above, I’d love to make it an error to define a new >> associated type with the same name as an associated type in an inherited >> protocol. It’s odd that we do so,

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

> On 25 Apr 2016, at 19:27, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0069: Mutability and Foundation Value Types" begins now and > runs through May 4. The proposal is available here: > > >

[swift-evolution] Disambiguate Return Type With Void

+1 > Also, technically we can assign a value to Void function This proposal will not disallow that. Just non-Void functions will be preferred when result is used. array.sort(..) // mutating let array2 = array.sort(..) // non-mutating, instead of array.sorted() I think, that's actually the best

[swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

Forgive me if this has been answered already, but is func isLessThanOrEqualTo(_ other: Self) -> Bool really needed? I understand the lack of trichotomy. But can’t this simply be implemented using the other existing methods? Consider that the consumers of the types will normally use the global

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

> * What is your evaluation of the proposal? +1 I concur with David Hart: Foundation becoming the base first-class cross platform library seemed concerning when Foundation was build from a paradigm of “Object Everything”. This fits far better with the Swift philosophy of value types

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

Please allow me to add my 2 cents. How I think about multi-line feature: it should allow to paste any text as-is, which will have no any special letters/symbols in it. Such text should be copied to variable *exactly* as typed inside source file. I want to be able to have in source file

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types

On 25.04.2016 20:18, Michael Peternell via swift-evolution wrote: Is "Self" dynamically dispatched? What would the following program print? In your example you can just replace "Self" to "self.dynamicType", the more questions appear if "Self" is used in protocol as result type and as

[swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

I agree with David. I don’t think I’ve ever omitted parenthesis in the argument list of a closure; not only that, but I think that omitting them in that case *reduces* clarity, making the closure harder to parse visually. Nicola > What is your evaluation of the proposal? > I reluctantly agree

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > > > func isEqual(to other: Self) ->Bool > > > func isLess(than other: Self) ->Bool > > > func isLessThanOrEqual(to other: Self) ->Bool > > > > I'm still not sure why these are methods instead

[swift-evolution] [Review] SE-0061: Add Generic Result and Error Handling to autoreleasepool()

> * What is your evaluation of the proposal? +1 for the change > * Is the problem being addressed significant enough to warrant a > change to Swift? It’s not really a significant issue, but since nothing will be broken, it should be fine. > * Does this proposal fit well with the feel and

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

Perhaps, with this thought in mind, we should consider making @objc into something more resembling the @available syntax. Getter selector, setter selector, copying, etc. could live there as well. Sincerely,   Zachary Waldowski   z...@waldowski.me On Tue, Apr 26, 2016, at 01:15 AM, Brent

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

I’m with Nicola on this one. Operators are currently odd in that they have to be declared globally. Everything else about protocol conformance is kept within the conforming type. - Dave Sweeris > On Apr 26, 2016, at 9:28 AM, Tony Allevato via swift-evolution >

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

I like this idea very much. I believe '&' should belong to instance variable, as it will be mutated, just like for inout parameter, so c&.frobnicate(i) let k = c&.frobnicate() very clear and explicit. Don't like the 'mutation' or even 'mut' as we'll have heavy code, as it is a word just like

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

> On Apr 26, 2016, at 10:03 AM, Nicola Salmoria via swift-evolution > wrote: > > it should be enough to do > > func <= (lhs: T, rhs: T) -> Bool > { > return lhs.isLess(than: rhs) || lhs.isEqual(to: rhs) > } > > Or is there some case of x, y where (x <= y) is

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

Note much more then just Apple's frameworks leverage the optional protocol feature of Objective-C. It really is tied to a feature of objective-c and its dynamic runtime. On Mon, Apr 25, 2016 at 10:30 PM Daniel Steinberg via swift-evolution < swift-evolution@swift.org> wrote: > I am very glad to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

+1 to Tony's write-up. On Tue, Apr 26, 2016 at 10:47 Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > That seems like a purely syntactic concern that could potentially be > addressed in other ways, though. I'm not sure the choice of "duplicate all > operators using

[swift-evolution] SE-0066 Reaction

Hi, I missed the original thread, but here are my thoughts on SE-0066 right after Chris's email ends with "thoughts?". Concern 1: I feel like we're forgetting about the functional programming syntax of declaring function types like this: A -> B -> C for a function foo(a: A, b: B) -> C This

Re: [swift-evolution] SE-0066 Reaction

On Apr 26, 2016, at 10:52 AM, Mishal Awadah via swift-evolution wrote: > Concern 1: > I feel like we're forgetting about the functional programming syntax of > declaring function types like this: > > A -> B -> C > > for a function foo(a: A, b: B) -> C This

Re: [swift-evolution] @noescape and nil

> On Apr 26, 2016, at 12:15 AM, Aleksandar Petrovic via swift-evolution > wrote: > > Hi Swift community, I have a question. > > This is a valid Swift code: > > func testFunc(times: Int, fn: ((Int)->Void)? = nil) { > guard let f = fn else { return } >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 12:36 PM, Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato > wrote: > >> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org> wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato wrote: > On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < > swift-evolution@swift.org> wrote: > >> > > func isEqual(to other: Self) ->Bool >> > > func isLess(than other: Self) ->Bool >> > > func

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

See inline. > Am 26.04.2016 um 19:36 schrieb Nicola Salmoria via swift-evolution > : > >> On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato wrote: >>> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 8:10 PM, Thorsten Seitz wrote: > See inline. > > Am 26.04.2016 um 19:36 schrieb Nicola Salmoria via swift-evolution < > swift-evolution@swift.org>: > > On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato > wrote: > >> On Sun, Apr 24,

[swift-evolution] @noescape and nil

Hi Swift community, I have a question. This is a valid Swift code: func testFunc(times: Int, fn: ((Int)->Void)? = nil) { guard let f = fn else { return } for i in 1 ..< times { f(i) } } And this is not: func testFunc(times: Int, @noescape fn:

Re: [swift-evolution] @noescape and nil

I think this is a bug similar to this one: https://bugs.swift.org/browse/SR-317 . Would you mind filing a bug report for it on bugs.swift.org ? – Another Alex > On 26 Apr 2016, at 09:15, Aleksandar Petrovic via swift-evolution >

Re: [swift-evolution] @noescape and nil

No one’s brought it up yet, but it seems totally reasonable. I’d even consider this a bug fix, not a real language change, but I’m not a core team member. Jordan > On Apr 26, 2016, at 00:15, Aleksandar Petrovic via swift-evolution > wrote: > > Hi Swift community,

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

> On 26 Apr 2016, at 14:48, Thorsten Seitz via swift-evolution > wrote: > >> Should the syntax be `x.=f()`? — Not necessarily. I kinda like James >> Campbell's idea of a `mutate` keyword. Consider the following: >> >> var numbers = [5, 12, 6, 2] >> mutate

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

That seems like a purely syntactic concern that could potentially be addressed in other ways, though. I'm not sure the choice of "duplicate all operators using verbosely-named methods" is the best one for the reasons I mentioned above, and the question of "how do we cleanly unify operators with

Re: [swift-evolution] Disambiguate Return Type With Void

> On Apr 26, 2016, at 06:57, Антон Жилин via swift-evolution > wrote: > > +1 > > > Also, technically we can assign a value to Void function > This proposal will not disallow that. Just non-Void functions will be > preferred when result is used. > array.sort(..) //

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> Le 26 avr. 2016 à 08:07, Chris Lattner a écrit : > > On Apr 25, 2016, at 10:48 PM, Gwendal Roué wrote: >>> Le 26 avr. 2016 à 07:17, Chris Lattner a écrit : >>> >>> On Apr 25, 2016, at 9:41 PM, Gwendal Roué via swift-evolution

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[[iOS messageWithData:ideas] broadcast] > On 26 Apr 2016, at 07:28, David Owens II via swift-evolution > wrote: > > What is your evaluation of the proposal? > I reluctantly agree with the proposal with the following caveat: I do not > agree with the rationale to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 11:29 AM Nicola Salmoria wrote: > On Tue, Apr 26, 2016 at 8:10 PM, Thorsten Seitz > wrote: > >> See inline. >> >> Am 26.04.2016 um 19:36 schrieb Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org>: >> >> On

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 26, 2016, at 11:42 AM, Chris Lattner via swift-evolution > wrote: > > On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution > wrote: >> That seems like a purely syntactic concern that could potentially be >> addressed

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

Again, +1 to Tony's analysis. In the context of numerics in particular, global functions and operators are very much "normal means," and if anything instance methods are rather "convenience." On Tue, Apr 26, 2016 at 13:36 Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > On

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

You'll have to forgive my ignorance on the matter because I'm also not a type checker expert. If compile-time performance concerns are the motivating factor, is it possible to address them in a different way that would not require trampoline code or public interface bloat, like hoisting operators

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

If this design is a workaround for type checker limitations, then perhaps comparison method names are better prefixed with an underscore and/or using abbreviated terms-of-art (eq, lt, lte, etc.)? As Tony points out, it seems tragic to promote to an equal footing with `2.0 + 2.0 == 4.0` the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 10:36 AM Nicola Salmoria wrote: > On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato > wrote: > >> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> > > func

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 26, 2016, at 9:19 AM, Jordan Rose via swift-evolution > wrote: > > I tend to agree. I’d like the inconsistency concerning operators and dispatch > to be resolved by investigating making operators into members, not by forcing > operators to be second-class

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution wrote: > That seems like a purely syntactic concern that could potentially be > addressed in other ways, though. I'm not sure the choice of "duplicate all > operators using verbosely-named methods" is the

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

> * What is your evaluation of the proposal? +1 I’ve always been bothered with the idea of Foundation becoming a first-class cross-platform library while breaking the core principles of Swift promoting value types. I’m extremely happen with this proposal. > * Is the problem being

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

I prefer the index() method name for this purpose, but I wonder if we might want to consider overloads for forward/backward, since not all indexes are bidirectional (or at least, not efficiently so), for example: index(_ index:Index, advancedBy:Index.Distance) -> Index index(_

Re: [swift-evolution] [swift-dev] [Compiler] Help IR gen in targetting MSVC

> On Apr 26, 2016, at 1:03 PM, Sangjin Han wrote: > The problem can be solved by modifying that code. Thanks you. I thought that > code will affect only to the CLong type not Int. It changes what 'long' gets imported as. If there's a Windows API defined using 'long'

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution > wrote: > > What is your evaluation of the proposal? > I reluctantly agree with the proposal with the following caveat: I do not > agree with the rationale to support being able to choose to omit

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> On Apr 26, 2016, at 5:56 AM, Vladimir.S via swift-evolution > wrote: > > On 26.04.2016 9:38, Goffredo Marocchi via swift-evolution wrote: > > > > Agreed, the exception for the parameter list in a closure declaration > > should be gone too potentially, I do not see

Re: [swift-evolution] Localization support for string interpolation

On 24.04.16 23:33, Chris Lattner wrote: > >> On Apr 21, 2016, at 12:42 AM, Daniel Höpfl via swift-evolution >> wrote: >> >> Hi there! >> >> TL;DR: Here’s my idea for a better localized strings handling in Swift. >> It includes both, support for string interpolation

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

on Tue Apr 26 2016, Thorsten Seitz wrote: > Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution > : > > I'd like to second James Campbell's suggestion of a `mutate` keyword. > Clarifying comments inline below: > > On 23 Apr 2016, at 00:24,

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

Comments inline. > Am 26.04.2016 um 15:32 schrieb Ted F.A. van Gaalen : > > Hi Michael > > What happens if a delimiter in this case: “”” > occurs embedded in the data? like so (two times here): that's a problem you always have. And I think pasting a few lines of text