Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

I would not use it. Somehow it gives me the creeps to leave something like ‘fatalError’ in a shipping application. During development it could make sense, but then again I like to keep development and shipping the same as much as possible. Regards, Rien Site: http://balancingrock.nl Blog:

Re: [swift-evolution] In-line scope designators

I don’t like this, it violates the locality principle. I.e. that all information that is needed to understand something is close by. But since it is not something that everybody has to use… I don’t object to it either. Regards, Rien Site: http://balancingrock.nl Blog:

Re: [swift-evolution] Yet another fixed-size array spitball session

While I’d like a fixed size array, I’d agree with Rod that this looks odd. Myself I use the name ‘array’ a lot in places where I get/need a temporary array that lives for a few lines only. So I am against using the keyword ‘array’. A name like SizedArray would seem more in-line with other

Re: [swift-evolution] [Pitch] Swift run Command

> On 15 May 2017, at 11:58, David Hart wrote: > >> >> On 15 May 2017, at 10:40, Rien wrote: >> >> >>> On 15 May 2017, at 10:12, David Hart wrote: >>> >>> On 15 May 2017, at 10:03, Rien wrote:

Re: [swift-evolution] [Pitch] Swift run Command

> On 15 May 2017, at 10:12, David Hart wrote: > > >> On 15 May 2017, at 10:03, Rien wrote: >> >> I always wondered why it did not exist already ;-) >> >> However, I am not sure if I like the “auto build” aspect. For example I may >> have started

Re: [swift-evolution] [Pitch] Swift run Command

I always wondered why it did not exist already ;-) However, I am not sure if I like the “auto build” aspect. For example I may have started working on a change, but quickly want to verify the exact old behaviour. Then I want to run the old build again. While this proposal does not make this

Re: [swift-evolution] [Review] SE-0178: Add unicodeScalars property to Character

• What is your evaluation of the proposal? +1 > • Is the problem being addressed significant enough to warrant a change > to Swift? Its not a change but an extension to the language that feels entirely natural. > • Does this proposal fit well with the feel and direction

Re: [swift-evolution] Proposal: Allow #if to guard switch case clauses

I hope this makes it through without generating a lot of extra discussion. I would love to have this in Swift 4, or the next regular update of xcode. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project:

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On 05 May 2017, at 09:59, Xiaodi Wu wrote: > > On Fri, May 5, 2017 at 2:56 AM, Rien wrote: > > > On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution > > wrote: > > > > On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution > wrote: > > On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev > wrote: > I’m not arguing to remove all labels in Swift. Labels are great, this is a > fact for sure. The point

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

I think your misunderstanding helped a lot of people understand what is at issue here :-) It did for me! +1 Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - A server for websites build in

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

+ 1 > On 02 May 2017, at 00:00, Martin Waitz via swift-evolution > wrote: > > Hello, > > Many of the listed package managers are for interpreted languages. > So after fetching all dependencies, your package is completely usable. It is > „installed locally“. > But

Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

I subscribed to the list, thanks. I guess security is something people “want to look into later”… and then somehow never get to it. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - A server

Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

Having just finished a client/server framework that builds on openSSL I sympathise with this proposal. However, I wrote a few blogposts about my experiences with openSSL. And those leads me to believe that there is not much interest in secure networking. The number of hits on those posts are

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On 02 Apr 2017, at 07:51, Karl Wagner via swift-evolution > wrote: > > Given the relationship to contains, why not keep it simple and go with: > > onlyContains(_ element:) > onlyContains(_ matching:) > > [9, 9, 9, 9, 9].onlyContains(9) // true > [1, 2, 3, 2,

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On 01 Apr 2017, at 16:10, David Hart wrote: > >> >> On 1 Apr 2017, at 11:32, Rien wrote: >> >> >>> On 01 Apr 2017, at 10:47, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> On Sat, Apr 1, 2017 at 3:40 AM, David Hart

Re: [swift-evolution] [Proposal] Factory Initializers

> On 01 Apr 2017, at 01:35, Riley Testut via swift-evolution > wrote: > > >> On Mar 20, 2017, at 8:07 PM, Greg Parker wrote: >> >> This needs more explanation. It is allowed for a subclass to implement a >> convenience initializer that has the

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> • What is your evaluation of the proposal? +1 > • Is the problem being addressed significant enough to warrant a change > to Swift? I do not see this as a problem, but as added functionality that would be beneficial > • Does this proposal fit well with the feel and

Re: [swift-evolution] Remove prefixes from all Apple frameworks

The problem with unprefixed names is name clashes with my own code. Not often, but often enough. Then you have to invent your owm prefixes. Besides, NS… and UI… make it much, MUCH more convenient to google… Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github:

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

> On 27 Mar 2017, at 16:46, Steven Knodl via swift-evolution > wrote: > > Late to the party here > > * What is your evaluation of the proposal? > I’m -1 on this. The proposal is not a difficult read, but may have been > simply more simply named “Remove Scoped

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

> On 26 Mar 2017, at 13:23, Andrey Tarantsov via swift-evolution > wrote: > > > What is your evaluation of the proposal? > > Very strong -1. Drew has said it all. > > A few extra points: > > * If you split a class into a bunch of extensions, chances are it's a

Re: [swift-evolution] [Pitch] Localized Swift Frameworks

> On 24 Mar 2017, at 21:40, Jean-Daniel via swift-evolution > wrote: > > >> Le 24 mars 2017 à 18:28, Jeff Kelley via swift-evolution >> a écrit : >> >> One of the things that struck me from today’s Apple press release about >> Swift

Re: [swift-evolution] [Draft] Package Manager Custom Targets Layout

Sounds good on a first read through. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 24 Mar 2017, at 21:26, Ankit Aggarwal via swift-evolution > wrote: > >

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

> On 23 Mar 2017, at 21:26, Jose Cheyo Jimenez <ch...@masters3d.com> wrote: > >> >> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On 21 Mar 2017, at 08:05, Rien <r...@balan

Re: [swift-evolution] Pitch: Partial Implementations

I think the access levels should be revised, no need to introduce a new concept. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 23 Mar 2017, at 19:12, Charles Srstka via

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

> On 21 Mar 2017, at 08:05, Rien wrote: > > +1 -1: I have revised my opinion. > >> • What is your evaluation of the proposal? > > Makes the language easier to understand, lowers cognitive load during coding. > I also hope this will pave the way for a overhaul of

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

> On 22 Mar 2017, at 10:53, Goffredo Marocchi via swift-evolution > wrote: > > > Sent from my iPhone > > On 22 Mar 2017, at 09:43, Brent Royal-Gordon via swift-evolution > wrote: > >>> On Mar 21, 2017, at 11:29 PM, Matt Whiteside via

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

+1 > * What is your evaluation of the proposal? Seems to remove magic, which is something I can support, even if it means refactoring existing code. > * Is the problem being addressed significant enough to warrant a change to > Swift? Neutral > * Does this proposal fit well with the feel

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

> On 21 Mar 2017, at 10:15, Jonathan Hull via swift-evolution > wrote: +1 Big Yes, collect the other stuff on access levels and modules too before implementing anything. > > I wonder if there is a way to basically accept that this is what we want to > do, but

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

> On 21 Mar 2017, at 08:55, Goffredo Marocchi <pana...@gmail.com> wrote: > > > Sent from my iPhone > >> On 21 Mar 2017, at 07:05, Rien via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> +1 >> >>> • What is

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

+1 > • What is your evaluation of the proposal? Makes the language easier to understand, lowers cognitive load during coding. I also hope this will pave the way for a overhaul of the access level system including modularization. > • Is the problem being addressed significant enough

Re: [swift-evolution] [Proposal] Factory Initializers

I just have to ask: why should a factory method be part of the language? I have nothing against it, I am just wondering if I am missing something. The way I see it everyone can add a factory initializer if he/she needs it. Why make it part of the language? Regards, Rien Site:

Re: [swift-evolution] Code blocks and trailing closures

> On 20 Mar 2017, at 15:42, Haravikk <swift-evolut...@haravikk.me> wrote: > > >> On 20 Mar 2017, at 14:24, Rien via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Another solution to the original problem would be to allow

Re: [swift-evolution] Code blocks and trailing closures

oss the window) >> to show block, but that makes it harder to show nested blocks. >> >> >>> On Mar 19, 2017, at 20:33 , Kenny Leung via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> I have proposed that a different keyword be

Re: [swift-evolution] Smart KeyPaths

> > On 20 Mar 2017, at 12:12, David Hart via swift-evolution > wrote: > > > >> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >> wrote: >> >> +1. This is my favorite solution so far. >> >> With ‘Person.keypath.name' it

Re: [swift-evolution] Code blocks and trailing closures

is something subjective). > Agreed. Rien. > On Wed, Mar 15, 2017 at 12:35 PM, Rien via swift-evolution > <swift-evolution@swift.org> wrote: > What does the following code fragment do? > > serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return

Re: [swift-evolution] Code blocks and trailing closures

nfused by this. How is a trailing closure different from >> >> > a code block in Swift? It’s basically the same thing with some extra >> >> > syntax sugar because it happens to be the last parameter of your >> >> > function. >> >> > >&g

Re: [swift-evolution] Code blocks and trailing closures

s (like > `forEach`) to support keywords like `return`, though I imagine this would > require some sort of macro system. > > Cheers, > Jaden Geller > >> On Mar 15, 2017, at 4:56 AM, Rien via swift-evolution >> <swift-evolution@swift.org> wrote: >> >

Re: [swift-evolution] Code blocks and trailing closures

s are indicating that your closure is immediately invoked. >> > >> > let someInt = { return 42 }() >> > print(someInt) >> > >> > let someClosureWhichReturnsAnInt = { return 42 } // You can reuse the >> > closure >> > print(someCl

Re: [swift-evolution] Code blocks and trailing closures

case return > will return from your closure with a value of Void. > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 15. März 2017 um 11:35:39, Rien via swift-evolution > (swift-evolution@swift.org) schrieb: > >> What does the following code fragment do? >&g

[swift-evolution] Code blocks and trailing closures

What does the following code fragment do? serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message); return } The only possible answer is: I don’t know. The problem is finding out what the “return” statement will do. Without knowing if the {...} is a code block or a trailing closure

[swift-evolution] SPM - Set 'Defines module' to 'yes' by default

When generating an xcode project with the SPM, the “Defines module” option is not set. Would it be possible to always set this option to ‘yes’ by default in the next release? This would make it easier to create modulair frameworks for inclusion in (other) Xcode projects. Regards, Rien Site:

Re: [swift-evolution] Infer types of default function parameters

0 Its not something I would use, but I don’t see why not. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 10 Mar 2017, at 22:40, Kilian Koeltzsch via swift-evolution >

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

> * What is your evaluation of the proposal? I like the way this provides more harmonisation with Swift coding style. Future extensibility seems to be well provided for. > * Is the problem being addressed significant enough to warrant a change to > the Swift Package Manager? If it were the

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On 06 Mar 2017, at 15:10, Karim Nassar wrote: > >> >> On Mar 6, 2017, at 3:04 AM, Rien wrote: >> > > I’m not dead-set on this approach, but as you say, it solves a *lot* of > problems that other approaches introduce. I do

[swift-evolution] Modules - an extremely simple approach

I do not believe I have enough language inside to actually propose a solution. Still I would like to show what I think is the most simplest and flexible way to create modules. Introduce the ‘module’ keyword to define a module. module To create an empty lexical module named “MyModule”:

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

>>> >>> I’m not dead-set on this approach, but as you say, it solves a *lot* of >>> problems that other approaches introduce. I do recognize the reasonableness >>> of the main argument against, that file location shouldn’t have such a >>> dramatic affect on behavior… *but* the fact is (whether

Re: [swift-evolution] [Draft] Really Simple Submodules

+1 for the simplicity. I like that. However I dislike the non-hierachical approach: It should not be possible for an ‘outsider’ to declare itself part of a submodule if the original developer of that submodule did not want that. I understand that the submodules are not exported through the

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On 05 Mar 2017, at 15:52, Karim Nassar via swift-evolution > wrote: > > >> On Mar 4, 2017, at 2:54 PM, Matthew Johnson wrote: >> >>> >>> On Mar 4, 2017, at 9:56 AM, Karim Nassar wrote: >>> >>> On Mar 3,

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On 04 Mar 2017, at 16:01, Matthew Johnson via swift-evolution > wrote: > > I have updated this proposal with a few more refinements based on yesterday’s > discussion. You can find the final proposal on Github: > >

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On 03 Mar 2017, at 18:54, Karim Nassar wrote: > > Thanks for your feedback. > > These are very fair concerns and point taken. There are other mechanisms we > could use to achieve similar ends, I’ll work on some additional ideas. > > How do you view the overall

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

I don’t like the file location based approach taken, see inline. Rien. > On 03 Mar 2017, at 16:24, Karim Nassar via swift-evolution > wrote: > > > I’ve read through the last couple of Swift (sub)Module proposals put forward, > and since my particular use-cases for

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Ah, the irony… Having argued against too much complexity, I now encountered an error in my software that shows why there might indeed be a need for “open” and “public”. In an API: class Foo { open func foo(options: Option ...) { foo(options) } open func foo(options: [Options]) { … }

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Just joking of course (???) Exposure levels: World, Module, File, Type (= [ W | M | F | T ]) Access control: Read, Write, Override, Inheritable (= [ R | W | O | I ]) let api = Access(w, [r, -w, -o, -i]) // Access must always be statically resolved let mod = Access(m, [r, w, -o, i]) let cust =

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Very well written. Personally I am in favor of very simple systems and to put the responsibility for an application by the application developer (not a library developer). Though I understand that in some cases (Apple!) the developer is the end-customer, and this creates special circumstances

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

While I am in favor of this, I do think this should not be a proposal on its own, rather it should be folded into a general overhaul of the entire access level structure. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock

Re: [swift-evolution] [Draft] Fix Private Access Levels

I don’t know if you want to add this to the ‘criticism’ or not. 1) The information content added by “fileprivate” is questionable because of the ‘soft default’: - People will switch from private to fileprivate without much thought if that is desirable or not. - Other people will default to

Re: [swift-evolution] [Pitch] Let's talk about submodules

Maybe we should try to collect what people want from submodules first. I wanted modules for organisational purposes, however with the arrival of SPM that need has been almost completely removed. At least to the point that I do not feel that they are absolutely necessary. Have the people who

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 20 Feb 2017, at 09:39, Goffredo Marocchi via swift-evolution > wrote: > > Please, almost anything but going back to the horrible Objective-C pattern of > private headers (that end up included on in the implementation files) :/. Why not a best of both

Re: [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

> On 19 Feb 2017, at 19:14, Chris Lattner via swift-evolution > wrote: > > >> On Feb 18, 2017, at 9:59 PM, Kevin Nattinger wrote: >> >> >>> On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution >>> wrote:

Re: [swift-evolution] A concern

://github.com/Balancingrock Project: http://swiftfire.nl > On 19 Feb 2017, at 18:55, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Feb 19, 2017, at 1:00 AM, Rien via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello All, >> &g

[swift-evolution] A concern

Hello All, Its Sunday, time for some reflection... One of the big plusses of Objective-C was that the entire manual was just a few pages long. I have not looked it up, but IIRC the entire manual describing the language was probably less than 50 pages. Much less if you subtract the filler

Re: [swift-evolution] final + lazy + fileprivate modifiers

A parabel: Nobody is going to invest a week of his time so save $1 of taxes per year. Yet somebody who receives those millions of dollars will invest -if need be- all of his time to keep it coming. Guess who wins? Same with private. There is no BIG harm. But a great many of very little minor

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On 18 Feb 2017, at 14:16, David Rönnqvist via swift-evolution > wrote: > > On 18 Feb 2017, at 09:30, Slava Pestov via swift-evolution > wrote: > >> +1, two small questions: >> >> - If two cases have the same base name but different

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On 18 Feb 2017, at 04:26, John McCall via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0155: Normalize Enum Case Representation" begins now and > runs through next Friday, February 26th. The proposal is available here: > >

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 16 Feb 2017, at 23:34, Slava Pestov via swift-evolution > wrote: > > While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

In essence this is about assistance from the compiler that a function marked ‘pure’ is indeed pure? I.e. an error message should be generated when a function marked as ‘pure’ is in fact not ‘pure’? If the answer to both questions is ‘yes’ then -not surprising- its a -1 from me. Unless there

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 16 Feb 2017, at 03:45, David Smith <david_sm...@apple.com> wrote: > >> >> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> >>> On 15 Feb 2017, at 17:02, Matthew Johnson <

Re: [swift-evolution] [Pitch] consistent public access modifiers

> > On 15 Feb 2017, at 19:27, Adrian Zubarev > wrote: > > Inline: > > -- > Adrian Zubarev > Sent with Airmail > > Am 15. Februar 2017 um 19:11:12, Rien (r...@balancingrock.nl) schrieb: > >> >> > On 15 Feb 2017, at 18:09, Adrian Zubarev

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 18:09, Adrian Zubarev > wrote: > > As I already said: > > • To make that feature happen, we need the protocol to be public > (regardless if you can conform to it or not). > • Today you can conform to every protocol because in

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 17:45, Matthew Johnson wrote: > > >> On Feb 15, 2017, at 10:35 AM, Rien wrote: >> >>> >>> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: >>> On Feb 15, 2017, at 9:59 AM, Rien

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution > wrote: > > A short example where I personally wanted a public-but-not-open protocol: > > public protocol SubscriptParameterType { > > // This property was needed to prevent the client from

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 17:02, Matthew Johnson wrote: > >> >> On Feb 15, 2017, at 9:59 AM, Rien wrote: >> >>> >>> On 15 Feb 2017, at 16:45, Matthew Johnson wrote: >>> On Feb 15, 2017, at 9:35 AM, Rien

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 16:45, Matthew Johnson wrote: > >> >> On Feb 15, 2017, at 9:35 AM, Rien wrote: >> >> >>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution >>> wrote: >>> >>> On Feb 15, 2017,

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution > wrote: > > >> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution >> wrote: >> >> >>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution >>>

Re: [swift-evolution] final + lazy + fileprivate modifiers

What problem do access levels solve? I can think of just one problem: prevent an API user from accessing a part of an interface that for syntactic reasons has to be in that interface, but should not be accessible. All the other uses are design oriented, and therefor highly debatable

Re: [swift-evolution] Simplifying Default Access Modifiers

+1 I think this is actually what most people would intuitively expect anyway. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 13 Feb 2017, at 10:02, Jonathan Hull via swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution > wrote: > > I think I we can live with the original three: public, internal, and private > > Where public is visible to all, > Internal is visible to all within the module, and private is visible only to >

Re: [swift-evolution] [Pitch] consistent public access modifiers

I admit that I have not followed all of this discussion, but as far as I see, we could equally well do this by calling “not-open” enum’s “final”. It seems like a better fit to me. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github:

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

> On 09 Feb 2017, at 18:29, Cihat Gündüz via swift-evolution > wrote: > > @Jan: Your arguments are very subjective if not even insulting and derogatory > to many people who invest a lot of time and effort in crafting those things > you despise so openly. Here are

Re: [swift-evolution] Warning when omitting default case for imported enums

, depending upon the nature of the enum and the >> logic to handle them. There is no “right” way to suggest, although for >> high-reliability code, default cases should usually be avoided in my opinion. >> >> >>> On Feb 7, 2017, at 11:49 AM, Rien via swift-evolution >>&

Re: [swift-evolution] Warning when omitting default case for imported enums

If you don’t want the default case, and if you like a warning free compilation, you need a way to suppress the warning. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 07 Feb 2017, at

Re: [swift-evolution] Warning when omitting default case for imported enums

-1 Reason 1: the “negative” behaviour you describe is actually exactly what I want to happen. Reason 2: Introducing a warning would also necessitate a warning suppression in order to have your code compile without warnings. But when you suppress, the purpose of the warning is nul and void.

Re: [swift-evolution] The lack of namespaces is leading people astray

I have been known to mimic namespaces as well, however now that SPM is here, I no longer see a need for it. Still, I won’t object to it. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl >

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

OTOH, looking at fixit and error messages can also aid in understanding Swift better. Seeing what happens when it happens is something I find quite useful. Not that I have anything against the proposal, but I do wonder if that is the best usage of available resources. A BIG OT warning: If

Re: [swift-evolution] Strings in Swift 4

Wow, I fully support the intention (becoming better than Perl) but I cannot comment on the contents without studying it for a couple of days… Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Would this be allowed ? enum foo { case bar(num: Int) case bar(str: String) case vee(val: Bool) } If so, would this still be allowed ? var a: foo = ... switch a { case vee: ... case bar: ... } Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github:

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

> On 18 Jan 2017, at 08:54, Jonathan Hull via swift-evolution > wrote: > > >> On Jan 17, 2017, at 7:13 PM, Dave Abrahams wrote: >> >> >> on Tue Jan 17 2017, Jonathan Hull wrote: >> >>> Bringing it back towards the initial post, what if

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

A guy named Matthias recently commented this on my blog: func == (left: Enum3, right: Enum3) -> Bool { switch (left, right) { case (.ONE, .ONE): return true case (.TWO(let str1), .TWO(let str2)): return str1 == str2 default: return false } }

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

I am a bit ambivalent on this, on the one hand I think that “catch all, bring down thread only” stimulate careless programming, and on the other hand it did save my beacon on more than one occasion. In a perfect world we should do without this kind of feature. In the real world we need it to

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

-1 Comments should be part of the “flow of thought”. Moving them away from where they are needed is counter productive. Note that you can never force a bad programmer to become good. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github:

Re: [swift-evolution] Generic Subscripts

> On 14 Jan 2017, at 18:45, Anton Zhilin via swift-evolution > wrote: > > I’m not sure, but I think that in this case the specific type of these values > is determined at runtime. > Then a safe approach would be separate string: String?, bool: Bool?, int: > Int?

Re: [swift-evolution] protocol-oriented integers (take 2)

+1 Any change of including “ranged integers”? I.e. an integer with a value that must fit in a predefined range? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 13 Jan 2017, at 21:47, Max

Re: [swift-evolution] Throws? and throws!

-1 I think the basic type system should remain free of such constructs. I.e. if a Throws? is necessary on a + operation between integers, then the integers should be encapsulated into their own type. In fact I am thinking lately of the “need” for a new type system in parallel to the current

Re: [swift-evolution] Consolidate Code for Each Case in Enum

+1 Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 13 Jan 2017, at 03:01, Tim Shadel via swift-evolution > wrote: > > Fantastic points, all. Let me reply to a few. > > First,

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

-1, ‘obtain' obfuscates the meaning of the “if” statement. Since it would (conceptually) introduce a new statement that is very similar to the ‘if’ statement and ‘guard’ statement it would probably cause even more confusion. Regards, Rien Site: http://balancingrock.nl Blog:

[swift-evolution] Cancelable named defer statements

Is there any interest in a proposal to introduce a named defer statement that can be cancelled? Lately I find myself writing this kind of code: func openFile(kind: String) -> UnsafeMutablePointer? { var file = fopen("MyFile.txt", "r") var closeFile = true defer { if

Re: [swift-evolution] Consolidate Code for Each Case in Enum

I have mixed feelings about this. I would like to see a solution to the exploding switch statements in an enum, and we have talked about that before on this list. However the solution as suggested seems deficient to me. First, A developer would have to look at an enum “extension” in order to be

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

+1 Why? well… that is difficult. Mainly because it “feels” right. Having read a lot of the discussion (but not all) it seems impossible to make a “must have” case for it. But on a more conceptual level this feels similar to the discovery of zero in mathematics. Regards, Rien Site:

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

A little more work, but I like this pattern. struct Person { let name: String let address: String let phone: String func name(_ n: String) -> Person { return Person(name: n, address: self.address, phone: self.phone) } func address(_ a: String) ->

  1   2   >