Re: [swift-evolution] Annotation of Warnings/Errors

+1 to the proposal +1 to teach how to remove live issues to beginners, so they have a chance to train at detecting errors without the compiler Pierre > Le 2 févr. 2017 à 17:48, Nicolas Fezans via swift-evolution > a écrit : > > +1 > > On Tue, Jan 31, 2017 at

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

,Sub) > a == c // One type is not a Sub, must compare using > ==(Super, Super) > > - Krl > >> On 20 Jan 2017, at 20:24, Pierre Monod-Broca via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> The way I understand it, it's a bad

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

The way I understand it, it's a bad idea to override == and != (or any infix operator) for Sub if Super has them and that's why the default implementation from Equatable only generates !=(Super, Super) and not !=(Sub, Sub) (and there is no ==(Sub, Sub) generated either). And it's a bad idea

Re: [swift-evolution] Compiler Optimization of Optional-returning Functions followed by '!'

It just occurs to me that you can't put none in a [T], so on optional subscript would only be get and we would need the current subscript beside anyway. I have no particular opinion on the main subject, I wonder what the order of magnitude would be that optimisation. Pierre > Le 20 janv.

Re: [swift-evolution] Testing enum cases with associated values

The last time I was in this situation, I resolved it by having a shadow enum with the same cases but without any associated value. I also created shadow enums for error enums. The shadow enum wouldn't have any associated value, and Int as RawValue, and I would also use it as an error code when

Re: [swift-evolution] Code comments that check code validity.

Amir's idea is interesting to me. But I like Xiadi's solution with unused closure, and I don't see a reason to put more effort into this. It works well with simple and complex cases, and anyhow, for complex cases, feature switches and/or branches are already suitable, like said before. Pierre

Re: [swift-evolution] "with" operator a la O'Caml?

Good point. Pierre > Le 20 déc. 2016 à 11:32, Jeremy Pereira <jeremy.j.pere...@googlemail.com> a > écrit : > > >> On 20 Dec 2016, at 07:54, Pierre Monod-Broca via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> But for a struct to

Re: [swift-evolution] "with" operator a la O'Caml?

But for a struct to be immutable, you don't need all its properties to be let. (I guess that's Derrick's point) ´´´ struct Person { /* . . . var properties . . . */ } let john = Person() // john is completely immutable ´´´ If a struct has var properties, you can do a mutable copy, change it,

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Just to share my feelings and ideas. It seems to me it would be better addressed by code review. Among other things it would start the conversation about what should be made public, what should not, and why. On the automated part, there could be tools detecting changes to the public APIs (and

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I like : - public - modulewide or moduleprivate or internal - filewide or fileprivate - private I really dislike interfile because the word exists and means something else I dislike intermodule, inmodule and infile because I don't find them intuitive at all. I prefer the -wide flavors because

Re: [swift-evolution] Thoughts regarding readable INTENT of Loop keywords

+1 with Taras > Le 31 mars 2016 à 09:55, Taras Zakharko via swift-evolution > a écrit : > > I do not see how this is more readable. The current for loop is perfectly > readable and conveys the intent very well IMO: it executes a code block FOR > every ELEMENT that

Re: [swift-evolution] [Draft] Adding a Build Configuration Import Test

Good points. Should we allow the following then? And then should Bar be imported if Baz is not present? #if import Foo.Bar && import Foo.Baz #endif I also want to mention other forms for further discussion: #if import Foo.Bar as FooBar #endif #if !import Foo #endif Pierre Le 23 mars

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

> > https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md • What is your evaluation of the proposal? +1 • Is the problem being addressed significant enough to warrant a change to Swift? Yes, I believe so. • Does this proposal fit well with the feel

Re: [swift-evolution] Lambda function syntax

I like that the closure parameters are inside the closure, to me it makes as much sense as outside. They're the input, so as much in as out. I have nothing against `in`, but I wouldn't be against a sensible replacement. I like `=>`, but I'm concerned it might be confused with `->` by beginners

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

erics idea. > > On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > +1 for `type`, it is consistent with `func`, `var` and `init`. It looks good > to me. > > eg: &g

Re: [swift-evolution] [swift-build-dev] [Proposal] Lock file for Swift Package Manager

> Le 23 déc. 2015 à 18:17, Max Howell via swift-evolution > a écrit : > >> Right. I didn't mean to insinuate we should be pulling fresh dependencies >> before each build. Here's the scenario >> >> * I'm working on a package that depends on FooPackage >>

Re: [swift-evolution] Proposal: Enum 'count' functionality

+1 for an ordered collection of all cases, it could be an ordered set to please proponents of a set. I have no strong opinions about the name `cases` is good, but I agree it begs to do ''for case in SomeEnum.cases'' `values` is good, and IMO it's consistent with `rawValue` when there is one,

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

I agree, David's proposal looks good. Matthew concerned are interesting, and I think David answered them well. Pierre > Le 23 déc. 2015 à 06:58, Thorsten Seitz via swift-evolution > a écrit : > > David's proposal looks good enough for me. > > With regards to