Re: [swift-evolution] [Pitch] #warning

On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution < swift-evolution@swift.org> wrote: > Tools like SonarQube can raise a "warning" for comments started with > "TODO:" or "FIXME:". Wouldn't it be more interesting if those could be > presented as warnings instead of using

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

Curious on the possibility of something like the following to denote a no return function? func foo() -> ! ...or mostly joking... func foo() -> (for thing like fatalError) func foo() -> (for things like dispatch main) Anyway I am generally -0.5 on this change without understanding if this

Re: [swift-evolution] Revisiting SE-0041 Names

I like how your suggestion reads. It will namespace all literal convertibles while also reading more clearly on what conforming to the protocol implies. I now understand the intent of the Syntax namespace however I think you suggested naming would be better. -Shawn On Wed, Jun 22, 2016 at 11:26

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0105: Removing Where Clauses from For-In Loops

I am -0.5 on removing the where clause. I will note that removing it now - given the appearing limited usage - shouldn't cause a large disruption to most users. It may allow us time to think more about it and things related to it since it can be added back at a later point without breaking swift 3

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

I am curious on the disposition of this discussion / proposal pitch. Has any additional effort taken place since this email thread tampered off? On Sat, May 14, 2016 at 2:40 AM Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > On May 14, 2016, at 3:51 AM, Michael Peternell

Re: [swift-evolution] [DRAFT] Enhancing the Platform Configuration Test Suite for Conditional Compilation Blocks

Regarding "Bitwidth describes the number of bits used to represent a number. This proposal introduces a bitwidth test with two options: 32 and 64."... I don't fully understand how this will work or in general how it will be used. - "used to represent a number"... What "number" (e.g. what

Re: [swift-evolution] API Guidelines: dropFirst?

I agree the essence of the "terms of art" can still exist in the base name while applying the "ed/ing rule". I would vote to have these renamed to better align with Swift and less with the terms of art. -Shawn On Thu, Jun 16, 2016 at 10:41 AM Patrick Pijnappel via swift-evolution <

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

See my email earlier in this thread about how to potentially deal with this leveraging fairly normal syntax we already have to support in swift. On Tue, Mar 15, 2016 at 1:34 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > Oddball cases: > > Global visibility, private

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

On Tue, Mar 15, 2016 at 2:05 PM Erica Sadun wrote: > I see two results on the gmane search and neither one seems to match what > you're talking about: > > http://search.gmane.org/?query=Scoped=Shawn=gmane.comp.lang.swift.evolution=relevance > > Do you have a direct link to

Re: [swift-evolution] [Draft] Introducing Build Configuration Tests for Platform Conditions

6 at 9:51 AM William Dillon <will...@housedillon.com> > wrote: > >> The vast majority of special cases I’ve seen and written are due to the >> size of Int, not a pointer per se. To clear up the confusion, how about we >> rename bitwidth to intwidth or intsize? >

Re: [swift-evolution] [Draft] Introducing Build Configuration Tests for Platform Conditions

I guess the fuzziness in my mind is when considering LP64, LLP64, etc. I believe swift attempts to avoid that by defining either 32 bit or 64 bit model. If that is universally the case then I think bitwidth is fine. If not then pointerwidth may be more correct. Those bridging to C would have to

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

True. I was thinking to much in the content of the stdlib only but with a builtin you can get things optimized away. On Tue, Mar 15, 2016 at 9:22 AM Dmitri Gribenko wrote: > A function can absolutely can do that, if it is implemented using a > builtin known to the

Re: [swift-evolution] [Draft] Introducing Build Configuration Tests for Platform Conditions

; - Will > > > On Mar 15, 2016, at 9:40 AM, Shawn Erickson via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I guess the fuzziness in my mind is when considering LP64, LLP64, etc. I > believe swift attempts to avoid that by defining either 32 bit or

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

On Mon, Mar 14, 2016 at 5:18 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Per Doug’s email, the core team agrees we should make a change here, but > would like some bikeshedding to happen on the replacement name for private. > > To summarize the place we’d like to

Re: [swift-evolution] [DRAFT] Introducing a Debug Build Configuration Test

You would likely want to ensure debug related code could be optimized away / or not be included in release builds. I am not sure how a function would achieve that. On Tue, Mar 15, 2016 at 9:15 AM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > > On Mar 14, 2016, at 2:04

Re: [swift-evolution] [Pitch] Make the first parameter in a function declaration follow the same rules as the others

I could have easily screwed up my grep but doing spot checks on the resulting data sets I didn't spot an issue. I did make assumptions about how well formed the data set was. [shawnce:~/Downloads/swift-3-api-guidelines-review-swift-3] [0:554]> grep -R "func [A-Za-z0-9]*([A-Za-z0-9]*

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

On Mon, Mar 14, 2016 at 8:36 PM Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > Another +1 for James' idea to use private(module), private(file), private: > - It avoids ambiguity whether internal/private/local is more restrictive > and replaces it with a single axis,

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

On Mon, Mar 14, 2016 at 5:18 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Per Doug’s email, the core team agrees we should make a change here, but > would like some bikeshedding to happen on the replacement name for private. > > To summarize the place we’d like to

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

On Wed, Apr 6, 2016 at 11:36 AM Pyry Jahkola via swift-evolution < swift-evolution@swift.org> wrote: > On 06 Apr 2016, at 21:30, Developer via swift-evolution < > swift-evolution@swift.org> wrote: > > > If you've ever gotten to the point where you have a sufficiently generic > interface to a

Re: [swift-evolution] Feature proposal: Range operator with step

On Wed, Apr 6, 2016 at 1:29 PM Pyry Jahkola via swift-evolution < swift-evolution@swift.org> wrote: > > On 06 Apr 2016, at 23:17, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > I don't think you can fix counterintuitive behavior with guidance. > >

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

I think the where clause should be moved to the end as you outlined an any constraints beyond simple statements of conformance to a protocol or superclass should only be allowed in the where clause. If someone desires to state simple conformance/superclass for a generic parameter they should be

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

I want to reiterate that I have objective-c code, others have objc code, and the cocoa, etc. frameworks have code that depend on optional protocol for things like (but not limited to) delegates. This is of course obvious but what seems to get lost in the discussion is that you can't always replace

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Thanks for the excellent writeup and thought on this. I strongly believe - as a protocol adaptor - that having the ability to know if a default implementation is provided in the interface I see. It would also be helpful if documentation (header docs) about the characteristics of the default

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

On Mon, Apr 11, 2016 at 1:01 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > > Compared to this: > > > > collection.index(5, stepsFrom: i) > > > > I would prefer any of these (ordered from least favorite to most): > > > > collection.index(distance: 5,

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

On Fri, Mar 25, 2016 at 4:57 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > I honestly still think "public, internal, private, local" is a better > taxonomy.. It's true that "internal" and "private" aren't automatically > ordered relative to each other (and

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

On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution < swift-evolution@swift.org> wrote: > > What is your evaluation of the proposal? > > I don't like "form" as a prefix. To me there is no difference between > `union` and `formUnion`: both sounds functional-style, and actually the >

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

On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson wrote: > On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution < > swift-evolution@swift.org> wrote: > >> > What is your evaluation of the proposal? >> >> I don't like "form" as a prefix. To me there is no difference

Re: [swift-evolution] [swift-evolution-announce] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

On Thu, Mar 31, 2016 at 9:43 AM Chris Lattner wrote: > That said, this is the sort of proposal that can have a profound impact on > the actual experience using unaudited APIs. The core team believes that > the experience will be good, but we would like to get some experience

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

On Wed, Apr 13, 2016 at 4:45 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: Updated proposal: > > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md I like the use of `location(...)` instead of `index(...)`. I strongly

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-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

I believe it was things like "+" and "-" for set union and subtraction, etc. -Shawn On Tue, May 24, 2016 at 4:16 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On May 24, 2016, at 6:09 PM, Brent Royal-Gordon via swift-evolution < >

Re: [swift-evolution] Support for coding styles and "swift-format" tool

I would love to see flexible formatting styles be more easily available like this. -Shawn On Tue, May 17, 2016 at 10:33 AM Daniel Martín wrote: > As Swift is getting traction in more and more platforms outside of > Apple, we can expect that many coding styles

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

I personally kinda want to see these namespaced instead of global functions. That could possibly allow clarity in naming. -Shawn On Sun, May 1, 2016 at 2:55 AM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > With the renaming proposed above, stride(of:) will

Re: [swift-evolution] End of source-breaking changes for Swift 3

See the thread about stabilizing CI. The locked master while they worked out issues with the CI systems. Last I read it should be unlocked soon. On Thu, Jul 28, 2016 at 8:30 AM Brian Gesiak via swift-evolution < swift-evolution@swift.org> wrote: > Apologies if this was announced elsewhere: is

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Thanks for the effort on the proposal and discussion and thanks to those working in the implementation. -Shawn On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > Wow, thanks! I’m delighted that Apple found this improvement to be worth >

[swift-evolution] Fwd: [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Oops missed sending to the list. -- Forwarded message - From: Shawn Erickson Date: Thu, Jul 21, 2016 at 7:50 AM Subject: Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly To: Tino Heth

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

I agree with your line of reasoning regarding not needing 'hiding' (leveraging order of lookup as you noted). On Thu, Jul 21, 2016 at 12:41 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 20, 2016, at 1:59 PM, Xiaodi Wu via swift-evolution < >

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

(Google inbox won't let me inline my comments) Thanks for the effort on iterating and refining this proposal. +1 on the proposal, more strongly favoring the first design. If my brain is working correctly it seems like we could start with the first design and if somehow problematic move to the

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Additional two "things" maybe considered equal in the chosen problem domain despite their identity (memory location, etc.) being different. Having the ability to supply custom hash and equality for types can be a useful tool in a developers toolbox. For example two pathways of code may create what

Re: [swift-evolution] [Proposal draft] NSError bridging

I did a quick read and this looks great! Thanks to you two for pulling this together. I will attempt a deeper read and comment as needed later today. I am interested in helping with this as possible. -Shawn On Mon, Jun 27, 2016 at 2:41 PM Douglas Gregor via swift-evolution <

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

I also feel that Swift should be held "hostage" to a term of art especially if the term is fairly badly named and/or unswifty. I feel the term of art can incorporated in the API docs and possibly expressed by the alias concept that has been discussed. I strongly encourage going with a swiftly

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

I would suggest something like the following (yeah I would URLComponents for this but this is just an example)... basically a short hand of some type for (a != nil ? a : b) to deal with optional in string construction. "http://\(self.username + "@" : "default")@

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Oops remove the duplicate "@" in my example. On Tue, Jul 5, 2016 at 7:27 AM Shawn Erickson wrote: > I would suggest something like the following (yeah I would URLComponents > for this but this is just an example)... basically a short hand of some > type for (a != nil ? a : b)

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

y to close a public class. -Shawn On Sat, Jul 9, 2016 at 9:37 AM Goffredo Marocchi <pana...@gmail.com> wrote: > > > Sent from my iPhone > > On 9 Jul 2016, at 14:11, Shawn Erickson via swift-evolution < > swift-evolution@swift.org> wrote: > > What I don't get in the

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

I fall more in Matthew side of this regarding sealed by default. On Sat, Jul 9, 2016 at 12:29 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote: > > > > > >> Of course it can be done either way. But there

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

What I don't get in the arguments against this capability is the fact that many constructs in Swift can't be subclassed. Are we going to prevent library developers from presenting those in the public API? Your ability to subclass things when not supported by the library developer is already going

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

I think folks are going in an unprofessional direction in this thread, let bring it back to a more positive direction please. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

Well stated and has pushed me into favoring the closed be default case. I favor being explicit and the default being safe (you can always unseal in a future revision if a need arises). Also as you note it won't prevent bad implementations but it will help library developers better bound their

Re: [swift-evolution] [Discussion][Pre-Proposal] diverges/converges methods for Collection (was: Proposal to copy C++'s mismatch)

Folks are focusing on Swift 3 and non-critical additive things aren't going to get attention. It is best to avoid discussion of non-critical additive proposals until the focus returns to future looking (e.g post Swift 3). On Thu, Jul 7, 2016 at 1:48 PM Daryle Walker via swift-evolution <

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

I concur on the general weakness of Apple's developer forums as they currently exist. On Thu, Aug 4, 2016 at 11:23 AM Jon Shier via swift-evolution < swift-evolution@swift.org> wrote: > Just wanted to point out that Apple’s forum software is pretty terrible, > even after two (apparent) rewrites.

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

Exactly. If you utilize a forum solution like Discourse you often will also still be able to support folks that want to deal with email. -Shawn On Tue, Aug 2, 2016 at 11:17 AM Tim Vermeulen via swift-evolution < swift-evolution@swift.org> wrote: > For what it’s worth: Discourse has a Mailing

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

Nice and swifty, +1 This is a nice addition to the standard library that removes a common reason C libraries had to be imported. On Thu, Jun 30, 2016 at 11:02 PM Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0113: Add integral rounding functions to

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

Note under the latest floating point and integer protocol proposals the operators you outlined are basically overlays of the protocol functions even abs is replaced with magnitude on a protocol. Sorry not in a situation to link out to the proposals. On Fri, Jul 1, 2016 at 7:51 AM Brad Hilton via

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

It does look like a huge benefit for many many current swift users. Thanks to the whole team trying to make this happen in Swift 3. On Fri, Jul 1, 2016 at 10:21 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 1, 2016, at 9:11 PM, David Waite via

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

I would print it out and staple a $20 to the back of it and drop it his way with a wink. ...on a more serious note I like this naming suggestion. +1 from me On Fri, Jul 1, 2016 at 9:00 AM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > The best way to pass the Dave Test is

Re: [swift-evolution] InternalString class for easy String manipulation

I would also like to understand the perceived problem for first time programmers. To me first time programmers would be working with string literals ("hello world"), string literals with values in them ("Hello /(name)"), doing basic string concat, using higher level API of string to do and find

Re: [swift-evolution] [Discussion] Sortable Attribute

I think a first class sort descriptor style would robustly solve most complex sorting needs. It can deal with multiple sort dimensions, etc. which an attribute wouldn't really solve without language complexity. On Wed, Aug 17, 2016 at 1:12 AM David Rönnqvist wrote: >

Re: [swift-evolution] Removing enumerated?

I use enumerated in many location in my code and have never expected it to be indexes but a counting of how many times I have looped. It says clearly what is does on the tin: "Returns a sequence of pairs (n, x), where n represents a consecutive integer starting at zero, and x represents an element

Re: [swift-evolution] Strings in Swift 4

On Thu, Feb 9, 2017 at 5:09 PM Ted F.A. van Gaalen wrote: > On 10 Feb 2017, at 00:11, Dave Abrahams wrote: > > > on Thu Feb 09 2017, "Ted F.A. van Gaalen" > wrote: > > Hello Shawn > Just google with any programming language name and “string

Re: [swift-evolution] Strings in Swift 4

On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr wrote: > On Feb 9, 2017, at 3:11 PM, Dave Abrahams wrote: > > > on Thu Feb 09 2017, "Ted F.A. van Gaalen" > wrote: > > Hello Shawn > Just google with any programming language name and “string manipulation” > and

Re: [swift-evolution] Strings in Swift 4

I also wonder what folks are actually doing that require indexing into strings. I would love to see some real world examples of what and why indexing into a string is needed. Who is the end consumer of that string, etc. Do folks have so examples? -Shawn On Thu, Feb 9, 2017 at 6:56 AM Ted F.A.

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

Big +1 to the proposal and +1 to support default values. On Thu, Jan 19, 2017 at 5:04 PM Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > Can we also add mention that default arguments on subscripts should work > as well? This will force whoever implements this to do it

Re: [swift-evolution] InternalString class for easy String manipulation

As stated earlier it is 2016, I think the baseline should be robust Unicode support and what we have in Swift is actually a fairly good way of dealing with it IMHO. I think new to development folks should have this as their baseline as well... not that we shouldn't make it as easy to work with as

Re: [swift-evolution] InternalString class for easy String manipulation

I like a "view" based system when looking at a Unicode string. It lets you pick the view of string - defining how it is indexed - based on your needs. A view could be indexed by a human facing glyph, a particular Unicode encoding style, a decompose style, etc. I think that is powerful, useful,

Re: [swift-evolution] private & fileprivate

So are folks saying remove the concept of file private and keep the new private behavior? ...or revert the whole thing? Also based on what do we really see an issue with the addition of fileprivate? It seems more theory then examples of problems in the discussions I have seen. -Shawn On Fri, Oct

Re: [swift-evolution] Protected Access

I agree with and also feel access modifiers / controls are missing and the ones we have may not be the best if you factor in these additional needs. I also agree that I would prefer the discussion be more focused on this type of thing. Thanks for capturing some of the things you have seen (I have

Re: [swift-evolution] private & fileprivate

is feature being based on assuming that file scope was added and serves no purpose when in fact we always had file private scoping. -Shawn On Fri, Oct 7, 2016 at 2:17 PM Zach Waldowski via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, Oct 7, 2016, at 02:08 PM, Shawn Erick

Re: [swift-evolution] private & fileprivate

I agree something like you suggest will give a lot of flexibility without - I think - the IMHO quirkiness of friends in C++. It seems like the access domains must? be limited to inside a module to avoid potential surprises from outside the module? -Shawn On Sat, Oct 8, 2016 at 3:38 AM Karl via

Re: [swift-evolution] class/struct inner member access scope classifier

If coming from that perspective if has only changed name to fileprivate from private and you can then ignore private if you don't find it useful. If anything it more clearly states in common language your intent then the old naming (especial compared to other languages). On Tue, Sep 27, 2016 at

Re: [swift-evolution] Mark protocol methods with their protocol

I agree with that. I believe I have more often run into name collisions for protocols with differing semantics then matching semantics. Actually far more often then both I have purposely used somewhat contrived naming in protocols to avoid collisions, if that can be avoided by leveraging the

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

Using sub-protocols may be sufficient and make sense... to be honest I haven't had the time to fully explore this space and convert some things I have done in objective-c to pure swift. I do wonder how often that those sub-protocols would degenerate into having single methods. In a nut shell it

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

I think you are fixating on my talk about imp caching instead of my main point about setting up the state of my delegator to avoid unneeded work when a registered delegate hasn't implement a delegation point. It an unrelated topic to what is being discussed. -Shawn On Tue, Nov 15, 2016 at 5:27

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

Again my point isn't worrying about point of calling out to the delegate but configuring my delegator to avoid a body of work or state management that is unneeded if the delegate doesn't care about some mix of potential delegation points. I was trying to point out things to consider for those

Re: [swift-evolution] Generic Subscripts

I have very similar needs as well to allow for things to be generic on return type. On Sat, Jan 14, 2017 at 5:50 AM Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > Where generic subscripts are concerned, there are a couple of different > things to express: > - Generic

Re: [swift-evolution] Generic Subscripts

I have a throwing style data marshaling layer that uses throwing and return type inference to make the code clean and validation automatic with the optional ability to return default values if error or missing value, etc. This is for validating data coming from external sources into our app.

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

I think at this point we really need to build a concrete catalog of "warts" that cause implementation details to leak out of a module to consumers of a module (by extension submodule). I think that is the first things that should be looked at when considering making any changes to the access

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

+1. Yeah well thought out and explained. All for consistency and favor being explicit. On Wed, Jan 4, 2017 at 7:01 PM Micah Hainline via swift-evolution < swift-evolution@swift.org> wrote: +1. Well thought out, it's bothered me too. > On Jan 4, 2017, at 7:34 PM, Rick Mann via

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

I am still on the -1 side of this. I leverage the swift 3 enhanced encapsulation aspects of private fairly heavily and would rather see any additional efforts take place on needs of exposing things for subclasses to work with while hiding them from clients of those classes (better then protected

Re: [swift-evolution] Type-based ‘private’ access within a file

Yeah I think the best course of action is to leave things alone until such time as we can more holistically work things as you outline. Folks can strive to use private as the default lesser then module access level with fileprivate remaining available for those code patterns that require it for

Re: [swift-evolution] Type-based ‘private’ access within a file

On Mon, Apr 3, 2017 at 8:38 PM Adam Knight via swift-evolution < swift-evolution@swift.org> wrote: > On Apr 3, 2017, at 8:11 PM, Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@swift.org> wrote: > > My remaining hope is that Swift will acquire a submodule design which > renders

Re: [swift-evolution] Type-based ‘private’ access within a file

On Wed, Apr 5, 2017 at 6:53 AM David Hart <da...@hartbit.com> wrote: > > > On 5 Apr 2017, at 13:51, Shawn Erickson via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Wed, Apr 5, 2017 at 4:31 AM Vladimir.S via swift-evolution < > swift-evolut

Re: [swift-evolution] Type-based ‘private’ access within a file

On Wed, Apr 5, 2017 at 4:31 AM Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On 05.04.2017 7:02, Chris Lattner via swift-evolution wrote: > > On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

I have a few cases like that in production code with an unthread safe private function shadows a more public function that applies thread safety for external callers, etc. -Shawn On Tue, Mar 21, 2017 at 9:37 AM Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > > > Fact is, you

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

-1 (strongish) on this proposal for the reason I comment earlier in the discussion thread. This weakens private for not an atypical use case of private that I currently have. It muddies the water between fileprivate and private making private more confusing and in away surprising. We have a clear

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> My hunch is that structs and enums where such volatile data exists are the > exception, not the norm, when it comes to considering equality. This > proposal is very much intended to be useful syntactic sugar for the common > case while not preventing any existing behavior (providing your own >

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

Can you ping the list when aspects of this work lands in master? I have real world code that I want to see how this new stuff shakes out when attempting to use. On Wed, Apr 26, 2017 at 9:24 AM Tony Parker via swift-evolution < swift-evolution@swift.org> wrote: > Hi Riley, > > On Apr 25, 2017, at

Re: [swift-evolution] Revisiting SE-0110

On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > > Le 6 juin 2017 à 15:30, Vladimir.S a écrit : > > I'm just trying to understand your opinion. > Let me know, what result do you *expect* for this Swift4 code given what >

Re: [swift-evolution] [Proposal] Random Unification

It would be nice to leverage range support instead of a start and end value IMHO. On Fri, Sep 8, 2017 at 9:52 AM Alejandro Alonso via swift-evolution < swift-evolution@swift.org> wrote: > Hello swift evolution, I would like to propose a unified approach to > `random()` in Swift. I have a simple

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

I so far am most in favor of mapSome out of the names I have seen followed by mapAndUnwrap (however the later is growing on me). To me the most important thing is when reading code that it is quick to understand generally what is going on followed by discoverability of a new comer. I think both

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Yeah but it seems clear from the return type so I am not sure that much confusion would really exist. On Mon, Nov 13, 2017 at 4:57 PM Brent Royal-Gordon <br...@architechies.com> wrote: > On Nov 13, 2017, at 10:11 AM, Shawn Erickson via swift-evolution < > swift-evolution@s

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

On Mon, Nov 13, 2017 at 10:02 AM C. Keith Ray via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 12, 2017, at 10:54 AM, Paul Cantrell via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Nov 11, 2017, at 8:35 AM, Gwendal Roué via swift-evolution < >