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] 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] 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

, 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] 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] [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] 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] 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] 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

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:

[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] [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] [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] 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] [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] [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] [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] 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] [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] [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 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 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 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 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 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: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] [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] 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] 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] 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] [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] [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] 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] [Pre-Proposal-Discussion] Union Type - Swift 4

A union in C is a type overlay, not a type selector. The mechanism for what you propose would probably be implemented quite differently (maintaining type safety). As such I believe it should not be called a union as that can put people (with C experience) on the wrong feet. Suggestion:

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] SE-0138 UnsafeBytes

Probably the biggest argument is that it will make the migration more palatable. Most (??) apps today use some form of communication, and proving a better pointer solution is a big selling point. I know that my migration would have been faster and more efficient… Rien. > On 02 Sep 2016, at

Re: [swift-evolution] [swift-evolution-announce] SE-0138 UnsafeBytes

> On 02 Sep 2016, at 22:34, Tony Parker via swift-evolution > wrote: > > > I would instead prefer to look at what we can do with adding API to the > existing types to cover this use case. You point out in the proposal that it > has become customary to use [UInt8]

Re: [swift-evolution] #pragma

Ah :-) Yes that could lead to unexpected behaviour of the IDE. However I would not qualify that as dangerous. The code is indeed excluded as was the intention. Re-introducing the #pragma for that purpose seems a bit OTT to me. Rien. > On 05 Sep 2016, at 10:37, isidoro carlo ghezzi

Re: [swift-evolution] SE-0138 UnsafeBytes

Please include this in Swift 3. I just performed a migration of client/server software from Swift 2.3 to Swift 3 beta in Xcode 8 beta 6. And though I like the UnsafeRawPointer approach, I believe this proposal is more Swift-like and is easier to understand. In fact I used to have my own UInt8

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

As much as I would like to get rid of the “Unsafe” prefix, for this change it should imo be considered “out of scope”. Since it is used for the other pointers, it should be used here also. Maybe a separate proposal to get rid of “Unsafe”? Rien > On 07 Sep 2016, at 14:48, Karl Wagner via

Re: [swift-evolution] Class scoped access level

> On 10 Sep 2016, at 14:16, T.J. Usiyan via swift-evolution > wrote: > > I am firmly against this. The 5 levels that we have cover us well and have > enough complexity already. Agree. > On Sat, Sep 10, 2016 at 5:23 AM, Tom Bates via swift-evolution >

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

Now that “Raw” is introduced, also using “Unsafe” seems redundant to me. So ditch the unsafe and just go for “withRawBytes” and “withMutableRawBytes”. I expect that most code that uses this type wil already have a name indicating that it concerns a byte buffer pointer, so “withRawBytes” should

Re: [swift-evolution] private & fileprivate

> On 08 Oct 2016, at 19:17, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Oct 8, 2016, at 12:02 PM, Karl via swift-evolution > wrote: > >> >>> On 8 Oct 2016, at 16:47, Braeden Profile

Re: [swift-evolution] private & fileprivate

Do language ships ever sail? New POV’s should always be welcome. Just spit it out… Rien. > On 07 Oct 2016, at 08:39, David Hart via swift-evolution > wrote: > > Hello community, > > From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access >

Re: [swift-evolution] private & fileprivate

+1 for me. I see a little benefit for teams that have multiple people working on a single file (not necessarily at the same time) where a case can be made for a distinction between fileprivate and private. Other than that there is imo no benefit. So to me the question is “is the benefit to

Re: [swift-evolution] [Proposal] Enums with stored properties

Maybe I am missing something, but is this what you want? class Size { let width: Double let height: Double init(width: Double, height: Double) { … } } enum Format { case SMALL case MEDIUM case LARGE var size: Size { switch self {

Re: [swift-evolution] private & fileprivate

> On 09 Oct 2016, at 19:22, Daniel Tartaglia via swift-evolution > wrote: > > the programer specifies exactly which methods can be used by which classes. That IMO is the only sensible solution. Everything else -even in the name of simplicity- will be insufficient

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

It took another good night’s sleep to be able to realise what I really wanted to express yesterday. It comes down to three points: 1) Protocol marking is not really a proposal, but a bug report. 2) I do not think it needs new syntax 3) There is probably a lot of code out there that “uses” this

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

Note: Second attempt, first mail was rejected ? That is correct Vladimir, at the point of writing an API you never know who will end up using it in which way. Hence the decision which flavour (of a function) to call should not be made by the coder writing the API but by the coder using the API.

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

Hello Vladimir, Going back to the original suggestion: 4.1 Different implementation for different protocols class Foo : ProtocolA, ProtocolB { implement(ProtocolA) func foo() {...} implement(ProtocolB) func foo() {...} } class Foo : ProtocolA, ProtocolB { implement ProtocolA {

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

Hello Martin, Adding protocol conformance via existing functions can be had in different ways, first it could be done via mapping rules. I.e. if the API user requests a function A.Foo.foo() and there is only a function A.foo() present, the language rules could allow this to be accepted as the

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

> On 23 Sep 2016, at 18:25, Vladimir.S wrote: > > On 23.09.2016 17:41, Rien wrote: >> Hello Vladimir, >> >> Going back to the original suggestion: >> >> /4.1 Different implementation for different protocols/ >> /class Foo : ProtocolA, ProtocolB {/ >> / implement(ProtocolA)

Re: [swift-evolution] [Idea] Typed Numerics

I programmed in Ada in about 1990 and used typed numerics all the time. Missed them ever since… I would suggest to take a look at Ada and steal the best features to implement typed numerics. struct Distance: Double(checkedBounds: (lower: 100.0, upper: 10_000.0), delta: 0.1, digits: 10) { … }

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

On non-enum values, yes I could support this. However I do not see this as a big enough issue. On enum values? no way…. Btw this would get rid of: let bytesSend = send(…) // returns an Int switch bytesSend { case Int.min ... -1: {…} case 0: {…}

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

In my code, I ‘use’ the forced coverage of the case’s to be reminded of area’s where I have to update my code when the enum’s change. I.e. choosing for an enum solution is partly motivated by the factor that case-coverage has to be complete. I’d hate to miss that. Rien. > On 03 Oct 2016, at

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

> On 03 Oct 2016, at 13:16, Ross O'Brien wrote: > > There has been a little discussion on this before, and I think there's a need > for something along these lines - I've written code where I've used 'guard' > to ensure that an Int was within a certain range, and

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

+1. I have several cases where I cannot use enums, this proposal would solve that. > On 03 Oct 2016, at 21:53, Adrian Zubarev via swift-evolution > wrote: > > I made a typo in my previous post. > > Bikeshdding with correct types: > > struct A : Hashable { /*

Re: [swift-evolution] [Proposal] Type Narrowing

> On 09 Nov 2016, at 10:51, Haravikk via swift-evolution > wrote: > > >> On 8 Nov 2016, at 12:22, ilya wrote: >> >> (1) You can define different methods with the same name on T and Optional >> (description is such an example). Then what

Re: [swift-evolution] [Proposal] Type Narrowing

I get narrowing, and have admittedly often wished for it myself. Hence I have kept out of this discussion. But the argument for cognitive overload is imo convincing. When we create examples, there is almost no (or even negative) cognitive load associated with narrowing. However when you get a

Re: [swift-evolution] [Proposal] Type Narrowing

> On 09 Nov 2016, at 07:51, David Hart via swift-evolution > wrote: > > >> On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution >> wrote: >> >> This looks like a lot of complexity for very little gain. >> >> Aside from

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

-1. If an API designer wants to allow access to a “hidden’ member, he should be in control of that access. The proposed chance simply opens up access completely and leads to API vulnerability. (I am in favour of a “friend” solution, in which the API designer explicitly allows access to

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

> On 17 Oct 2016, at 19:47, Jonathan Hull wrote: > > First, let me say, thank you for your feedback. Just because I am arguing > against others' points does not mean that I don’t appreciate those points. > >> On Oct 17, 2016, at 12:37 AM, Rien wrote:

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

I have tried to like this because at first it seems like a good idea. But having let it shimmer for a while, I simply cannot muster the enthusiasm for it. Using “~=“ does not ‘feel’ right to me. Especially for a code breaking change at this stage. There are probably already a number of user

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> On 25 Oct 2016, at 14:15, Haravikk wrote: > > Lastly, on it being more readable the issue isn't general readability but > rather discoverability. If you see "if x matches .some(let y)" or "if x is > let y?" then there's some immediate context for what's going

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

“culturally offensive” is not a logical argument. A programming language should be logically consistent no matter how many cultures are offended by it. If Swift is driven by SJW’s then very quickly it will cease to be an effective language. Having said that, I cannot think of a logical reason

Re: [swift-evolution] [pitch] Implementation composition

I like that. Have you considered the following? protocol foobar { func foo() … func bar() ... } class A: foobar { …} class B: foobar { let a = A() implements foobar.foo let b = A() implements foobar.bar } Regards, Rien Site: http://balancingrock.nl Blog:

Re: [swift-evolution] [Pitch] Named subscripts

> On 18 Nov 2016, at 11:45, Adrian Zubarev via swift-evolution > wrote: > > The reason here is because the setter acts like semi-schema setter. Ah, ok. Just wondered because I had a similar case in SwifterJSON. Eventually I settled for the absence of user-supplied

Re: [swift-evolution] [Pitch] Named subscripts

> On 18 Nov 2016, at 10:25, Adrian Zubarev via swift-evolution > wrote: > > Thank you guys for all your suggestions so far. > > I understand the idea behind the generic subscript here, they are neat and > highly needed, but even this approach won’t solve my issue

Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types

> On 21 Nov 2016, at 11:52, Jeremy Pereira <jeremy.j.pere...@googlemail.com> > wrote: > > >> On 21 Nov 2016, at 08:42, Rien via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Sure you can do that, but I rather write: >> >

Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types

Imo, it does not need extreme nested code to be useful. I find that more than 1 level of nesting tends to create obfuscation. Probably because we loose the ability to associate type C with type A. By allowing "struct A.B.C" it is very clear that C does indeed depend on A. However, I can already

Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types

Sure you can do that, but I rather write: struct A.B {…} than extension A { struct B {…} } The first seems much “swiftier” to me. In fact, now that this “obvious” dot-notation has been pointed out, I wonder why this was not the initial implementation instead of the “extension” keyword. Was

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Said differently: A monkey with a tool is still a monkey. I.e. Swift cannot force somebody to become a good programmer no matter what rules it imposes. As far as limiting personal freedoms goes: everybody (kid’s included) should be able to use whatever pleases them - within the possibilities of

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

> On 29 Oct 2016, at 04:22, Xiaodi Wu via swift-evolution > wrote: > > The other has to do with expanding Swift standard library and core library > APIs beyond the ASCII character set. I'm -1 on that for the reasons I've > outlined above. Reworded, a very good

Re: [swift-evolution] guard let x = x

+1 Can “unwrap” be used anywhere else? If not, why not remove the “guard” altogether? I.e. unwrap foobar else { … } Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 29 Oct 2016, at 00:34,

Re: [swift-evolution] guard let x = x

Please ignore, the mail was sent in error. > On 02 Nov 2016, at 07:13, Rien via swift-evolution > <swift-evolution@swift.org> wrote: > > If using “unwrap” in itself, then it should be statement that only unwraps, > hence the > > Regards, > Rien > > Site:

Re: [swift-evolution] guard let x = x

If using “unwrap” in itself, then it should be statement that only unwraps, hence the Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 02 Nov 2016, at 02:47, Dany St-Amant via

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

> > Swift is a language being designed for the next 20-30 years, we shouldn’t be > limiting ourselves based on technology that is already being replaced (as you > mentioned many of the devices people use everyday already have a soft > keyboard… and Ive said the TouchBar was just the beginning

Re: [swift-evolution] [Proposal] Enums with stored properties

I read Braeden’s example such that this proposal is in reality “just” syntactic sugar. AFAIAC it does not change how enums are implemented after compilation. Like sugar, it makes working with enums clearer and therefore easier. All initialisation values are defined right there with the ‘case’

Re: [swift-evolution] private & fileprivate

> On 14 Oct 2016, at 06:03, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Daniel, I would be interested to hear what, exactly, are the benefits your > project has realized from the new “private” compared to the old “private” > (which is now called

Re: [swift-evolution] [Proposal] Enums with stored properties

> On 12 Oct 2016, at 21:21, Charles Srstka via swift-evolution > wrote: > >> On Oct 11, 2016, at 8:51 PM, Xiaodi Wu wrote: >> >> On Tue, Oct 11, 2016 at 8:21 PM, Charles Srstka via swift-evolution >> wrote: >>> On

Re: [swift-evolution] [Proposal] Enums with stored properties

I’d give a +1 for the suggestion of Braeden. Mateusz, you lost me with “store some extra data”. Does that mean something extra besides the code that Braeden suggested? Rien. > On 12 Oct 2016, at 00:13, Mateusz Malczak via swift-evolution > wrote: > > That's exactly

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

Specifically, I don’t care much. Say -0.1 :-) In general I am against “savings lines”. While very short modules (< 10) do indeed profit from having fewer lines, most modules don’t. Having a few more lines, even empty ones, can do a lot to improve code readability imo. Probably my Ada experience

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

Will discprivate be next? and then systemprivate? -1 Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 08 Dec 2016, at 12:27, Adrian Zubarev via swift-evolution >

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

big file, with several classes. Having a folderprivate access level > would be one possible solution to this. > >> On 8 Dec 2016, at 13.22, Rien via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Will discprivate be next? and then systemprivate? >

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

> On 12 Dec 2016, at 07:23, Benjamin Spratling via swift-evolution > wrote: > > > > -Ben > > Sent from my iPhone. > >> On Dec 11, 2016, at 11:43 PM, Brian Gesiak wrote: > >> Maybe your goal is to ensure that other programmers don't

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] 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] Swift evolution proposal: introduce typeprivate access control level

And the funny thing is, we don’t actually _need_ access control levels. The only purpose of access control is to enhance security/reliability by imposing restrictions on other programmers (API users). It seems to me that in almost all discussions the arguments are mostly backwards: i.e.

[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] [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:

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] Add ability to validate collection indices

I should clarify: “works only part of the time” was meant to say that it does not cover all cases. Sometimes a warning will be given and sometimes not. When referring to time I was thinking of the programmer, not of compilation or execution time. I think that “partially detectable” features

Re: [swift-evolution] Add ability to validate collection indices

Solutions that work only part of the time will raise expectations of the user only to crush hem later when they fail. It will likely generate a number of “bug” reports that must then be explained. I would suggest that functionality like this should only be applied to custom types, never on the

  1   2   >