Re: [swift-evolution] Simplifying Default Access Modifiers

[David Goodine via swift-evolution]

I think having a different default access for nested-scope adds a significant 
amount of cognitive complexity for not much value.  I understand that structs 
as nested types are often used to communicate values outside the score 
(internal even), so public will be required often in these cases.  But, then 
the question is what about structs that are purely for internal use, which 
happens just as often? Or classes?

Furthermore, you can achieve the same level of clarity without source-breaking 
changes to the language simply by better code organization, as in:

public struct MyStruct {
public var a:Int
public var b:Int
public var d:Int

private var c:Int
}

-d


> On Feb 13, 2017, at 4:02 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I would like to propose a change to the default access modifier within an 
> enclosing scope.  The default for top level definitions would stay internal, 
> but anything within a scope would by default have the same visibility as it’s 
> enclosing scope.
> 
> The main reason for this is readability/maintainability, and having the 
> intention clearly stand out.  It would also reduce a great amount of 
> boilerplate.  It also matches the mental model of how scopes normally work 
> regarding inheritance of visibility/properties (which means less to teach 
> newbies).
> 
> Right now if I want to make a type and all of it’s vars/methods public, I 
> have to mark each individual var/method public, which leads to a lot of 
> boilerplate/noise and makes everything harder to read:
> 
>   public struct MyStruct {
>   public var a:Int
>   public var b:Int
>   private var c:Int
>   public var d:Int
>   }
> 
> Notice that the private var doesn’t really stand out as such very well.  
> Also, it is exceedingly rare (at least in my own coding style) that I 
> actually want an internal variable unless the type itself is internal, and in 
> those cases, I would like that choice to stand out as deliberate the same way 
> I want ‘private' to stand out.  As it stands, I wait until I think I am done 
> modifying a type to mark it public because of the extra noise generated.  I 
> also make a point to write ‘internal' for things that I explicitly want to 
> restrict to internal.
> 
> Consider the alternative:
> 
>   public struct MyStruct {
>   var a:Int
>   var b:Int
>   private var c:Int
>   var d:Int
>   }
> 
> Now the fact that I have chosen to make ‘c’ private really stands out much 
> better.  When revisiting the code in 6 months, the struct is much more 
> “glance-able” (as a friend of mine likes to say).
> 
> Note also the nuance that I didn’t say that those vars were marked public (or 
> had the same modifier), I said that they had the SAME VISIBILITY as the 
> enclosing scope (which in this case happens to be public).  This is a concept 
> which is hard to express currently, and IIRC this is what we had to do to 
> make the edge cases of swift 3’s private modifier work properly.  
> 
> Basically, it already works this way for ‘private’, ‘fileprivate’, & 
> ‘internal’, just not for ‘public’ or ‘open’… which can be surprising, 
> especially since you don’t discover these differences until you are working 
> across modules.  We should just extend that mental model up to include public 
> and open.  Migration would just take internal variables of public/open types 
> and mark them explicitly with the word ‘internal'.
> 
> Thanks,
> Jon
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[David Goodine via swift-evolution]

I'm not familiar with all of the discussions in other threads relating to this 
issue that some are here, so forgive me if I'm running over old ground.

Looking back at the original use case that David B. posted my first instinct 
was that this is a case that would best be solved by adding a compiler 
warning/error based on any function signature that matches a protocol signature 
but differs in the types.

My opinion is that naming a function that is so similar to a protocol function 
but clearly has a different signature is a bad idea and at least should be a 
warning. If Swift wants to be opinionated about it, it could become an error.

But looking at Vladimir's response, one thing that caught my interest was the 
idea of an 'implements' keyword. I think it might be a good addition to the 
language because it a) avoids this whole class of programming mistakes and, 
more importantly, b) strengthens the 'intention' of the programmer implementing 
the protocol, similarly to the way 'override' works for inherited functions.

One of the things I really like about Swift is that in many cases it requires 
programmers to explicitly state their intent when writing code (i.e. override). 
I think Vladimir's suggestion could do the same for protocols and should be 
considered. 

Sent from my iPhone

> On Sep 16, 2016, at 6:28 PM, David Beck via swift-evolution 
>  wrote:
> 
> Yeah, I figured it had probably come up before since I don’t follow evolution 
> that closely, but it is, in my opinion and experience, Swift’s last pitfall. 
> So many other pitfalls from ObjC and other languages have been solved with 
> Swift, including this exact one (when it comes to subclassing). If we are 
> going to say that it is a big enough problem to solve with a language feature 
> for subclasses, it really seems like it would make sense to solve it for 
> protocol conformance.
> 
> > On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via 
> > swift-evolutionwrote:
> > > 
> > > We've had this discussion on the list multiple times already. The gist of 
> > > the difficulty here is that most proposals for a mandatory keyword don't 
> > > permit retroactive modeling, so it's a no-go. On the other hand, the core 
> > > team seems to take a dim view to optional syntax, since that's more in 
> > > the ballpark of linters.
> > Numerous solutions to your objection have been proposed; you always simply 
> > dismiss all of them in favor of your dogmatic stance. It’s really quite 
> > tiring. You can have this and support retroactive modeling; you just might 
> > need to have a separate syntax for retroactive conformances. You keep 
> > bringing that up as a hard-and-fast objection, but you know what? Maybe 
> > retroactive conformancesshouldhave a separate syntax, because they’re not 
> > saying the same thing! One is saying "here are some methods that will make 
> > this type conform to this protocol”, where the other is saying “this type 
> > already has the methods that conform to this protocol somewhere.” These are 
> > not the same thing, and it might be confusing to see a conformance 
> > declaration and assume it’s the former when it’s actually the latter, and 
> > then have trouble finding the conformances. Maybe it would actually make 
> > your code clearer if retroactive conformances were required to declare 
> > “this method exists somewhere else already.” Maybe you could even 
> > command-click on it and jump to the actual declaration. Anything would be 
> > better than the current situation, because:
> > 
> > The reason this keeps coming up is because it’s a real problem. I myself 
> > have started taking up the practice of always using copy-and-paste to 
> > declare conformances to protocols, because otherwise the chances of 
> > mistyping something and having the bug not manifest itself until runtime is 
> > simply too high. This is not a “linter” problem; this affects basic 
> > functionality and makes protocols, honestly, really dangerous to use. For a 
> > language that bills itself as “protocol-oriented”, it’s really quite 
> > damning that its protocol support is this brittle and fragile compared to 
> > its support for traditional inheritance. I’ve been bitten by this enough 
> > times by now to somewhat regret the decision to go with a protocol-based 
> > design. This is a real shame because conceptually, the idea of Swift’s 
> > protocol-based design is really cool.
> > 
> > Charles
> > 
> > 
> > 
> >  
> 
> 
> David Beck
> http://davidbeck.co
> http://twitter.com/davbeck
> http://facebook.com/davbeck
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Goodine via swift-evolution]

First off, Chris made it clear dealing with this isn't a priority for Swift 4 
so take my comments (inline below) with a grain of salt. At least for the time 
being this horse should Rest In Peace. 

> On Oct 26, 2016, at 11:58 AM, Erica Sadun <er...@ericasadun.com> wrote:
> 
> 
>> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hey all,
>> 
>> As usual, apologies if this horse was beaten ages ago before I joined the 
>> mailing list, but thought I would bring this up.
>> 
>> I was typing the above (for the hundredth time) the other day and I was 
>> wondering whether it might be worth considering offering a shorter syntax:
>> 
>> guard let x, y, z else {…}
>> 
>> I was never convinced why implicit nil checks (i.e. if x {…}) were such a 
>> bad thing.  But now in Swift it seems that it would be much more convenient 
>> to be able to simply skip the assignment part of the expression and define 
>> the above as guaranteeing and unwrapping x, y and z in the appropriate scope.
>> 
>> I think with such powerful and already compact expressions now wanting to 
>> get on the same line,adding this would make the language even more compact 
>> and elegant.  It could be added as a non-source-breaking change, still 
>> allowing x = x for those who prefer it, but could significantly tighten up 
>> such uses, which I’m finding are ubiquitous in my code.
>> 
>> Any thoughts?
>> 
>> -d
> 
> There are safety arguments to be made for introducing a way to bind an 
> optional to a shadowed variable that is guaranteed to be the same name 
> ensuring the conditionally bound item does not accidentally shadow any other 
> item. 
> 

Chris also raised this in a comment in this thread, and I agree with Swift's 
philosophy that terseness shouldn't compromise clarity of intent. 

What I don't get is why 'let x = x' is any clearer than the alternative I 
suggested. It's intent is only clear because the language defines it as such. 
In fact, I would argue that to programmers familiar with most other popular 
languages, it's intuitively unclear, even meaningless (except for being a rare 
reference to a 1980s Laurie Anderson song). 

I was simply suggesting that since neither is a familiar syntax, Swift could 
simple "define it as such" in a more compact (and as Chris pointed out, more 
DRY form).

That said, I do like your earlier proposal to introduce the 'bind' form (and 
agree with Chris that 'unwrap' would be clearer). Perhaps that's the way to go 
when it's time to tackle the issue. 

-d

(p.s. I'm still secretly trying to work a reference to the Dead Parrot sketch 
to issues like these. Perhaps one day...)

> Your initial suggestion doesn't work as overloading "let" confuses rather 
> than clarifies this process. In February, I brought up `bind x` to mean 
> "conditionally bind x to x, and produce a conditional fail if that's not 
> possible", with the hope that "bind self" could be used in closures. Under 
> that scheme your example would read:
> 
> guard bind x, bind y, bind z else { ... }
> 
> "The bind thread" was discussed during the first week of February 2016. Joe 
> Groff had said: "If you all are serious about this, I think you should start 
> a new thread about it."  I thought it was worth a serious discussion just so 
> it could be evaluated and either adopted or discarded and dropped forever. 
> The arguments for:
> 
> * Simplifying an mildly complex and potentially misleading statement 
> * Creating a deliberate and controlled rather than accidental shadowing style
> 
> The discussion petered out, with Kevin Ballard making the strongest case 
> against: "If your goal here is to just avoid having to write the `= foo`, 
> then I disagree with the whole motive. If your goal here is to just use a 
> keyword `bind` instead of `let` (e.g. if you want to use `if bind foo = foo { 
> ... }`), I still disagree, because this new keyword serves no purpose. `if 
> let foo = bar { ... }` is not "fundamentally different" than `let foo = bar`, 
> it's still binding a new identifier to a value, the only difference is it 
> binds it to an optional value. And it's really just a specialization of `if 
> case let foo? = bar { ... }`. I've asked in the past about whether it's worth 
> keeping the special case around now that we have `if case let` (or more 
> specifically, if we should just turn `if let` into the generalized version, 
> so you'd say `if let foo? = bar {... }`) and the answer from the core team 
> was that they already tried it internally and found that the usage of 
> optionals was so prevalent that t

[swift-evolution] Constant initialization and unreachable code.

[David Goodine via swift-evolution]

Hey all,

I don’t know if this is really an ‘evolution’ topic per se, and I’m not on 
Swift Dev, but thought someone here could shed some light on this.

Often when developing code, if I need create mode switches (constant Bools) so 
that I can move back and forth between different features/implementations for 
testing, developing experimental features, migration, etc.  Currently if I 
write the following:

let useFoo = true

if useFoo {
// Foo code
} else {
// Non-Foo code
}

I will get compiler warnings either way that there’s unreachable code based on 
the value of useFoo.  That makes sense in most cases, but in some cases I need 
to leave the code as is for a while, and I hate leaving long-standing compiler 
warnings in production code.  (If it’s yellow, you need to pay attention to 
it.)  So I poked around and discovered that if I use the following declaration 
of useFoo, the warnings go away.

let useFoo = { return true }()

So, the question is, is this intentional? The compiler could certainly 
ascertain that useFoo will always be true and carry out the same dead code 
detection as for the first declaration.  If this isn’t intentional, and the 
compiler may at some point optimize away the closure and trigger dead code 
warnings, I might come up with a proposal that there is some idiom that allows 
one to do the above without the warnings.  I’m really not a fan of #define 
(because it’s just butt-ugly in such a beautiful language), but its existence 
is unavoidable for some cases.  

And, as I write this, I realized I haven’t tried declaring useFoo as var, but I 
expect that would trigger a warning that useFoo is not modified and should be 
defined by let.  I think this is a use case that, for practical purposes, 
should be covered to allow this type of evolution of code without generating 
warnings.  If the current behavior is intentional and going to stay, then 
that’s probably the best solution.

-d

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

Re: [swift-evolution] Constant initialization and unreachable code.

[David Goodine via swift-evolution]

William and Alex, thanks for the reply.  I’m aware of the compile-time option.  
My post was originally to ask if the difference between constant and closure 
initialization for constants was intentional (and likely to remain) or just a 
temporary idiosyncrasy.  I find #ifdef to be ugly and like prefer to avoid it 
unless absolutely necessary.  Thanks for the 
head up on Active Compilation Conditions William, I wasn’t aware of it.  
Anything I can do to avoid the Build Settings tab is more than welcome.
-d


> On Oct 19, 2016, at 1:57 PM, William Sumner <prestonsum...@me.com> wrote:
> 
> 
>> On Oct 19, 2016, at 5:50 AM, David Goodine via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hey all,
>> 
>> I don’t know if this is really an ‘evolution’ topic per se, and I’m not on 
>> Swift Dev, but thought someone here could shed some light on this.
>> 
>> Often when developing code, if I need create mode switches (constant Bools) 
>> so that I can move back and forth between different features/implementations 
>> for testing, developing experimental features, migration, etc.  Currently if 
>> I write the following:
>> 
>> let useFoo = true
>> 
>> if useFoo {
>> // Foo code
>> } else {
>> // Non-Foo code
>> }
>> 
>> I will get compiler warnings either way that there’s unreachable code based 
>> on the value of useFoo.  That makes sense in most cases, but in some cases I 
>> need to leave the code as is for a while, and I hate leaving long-standing 
>> compiler warnings in production code.  (If it’s yellow, you need to pay 
>> attention to it.)  So I poked around and discovered that if I use the 
>> following declaration of useFoo, the warnings go away.
>> 
>> let useFoo = { return true }()
>> 
>> So, the question is, is this intentional? The compiler could certainly 
>> ascertain that useFoo will always be true and carry out the same dead code 
>> detection as for the first declaration.  If this isn’t intentional, and the 
>> compiler may at some point optimize away the closure and trigger dead code 
>> warnings, I might come up with a proposal that there is some idiom that 
>> allows one to do the above without the warnings.  I’m really not a fan of 
>> #define (because it’s just butt-ugly in such a beautiful language), but its 
>> existence is unavoidable for some cases.  
>> 
>> And, as I write this, I realized I haven’t tried declaring useFoo as var, 
>> but I expect that would trigger a warning that useFoo is not modified and 
>> should be defined by let.  I think this is a use case that, for practical 
>> purposes, should be covered to allow this type of evolution of code without 
>> generating warnings.  If the current behavior is intentional and going to 
>> stay, then that’s probably the best solution.
>> 
>> -d
> 
> You should use Active Compilation Conditions to create flags for conditional 
> compilation you can check with #if. If you’re not yet using Xcode 8, you can 
> manually define the flags under the Other Swift Flags build setting (e.g., 
> -DUSEFOO).
> 
> Preston

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

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

[David Goodine via swift-evolution]

One thing I really like that Erica mentioned in the earlier discussion is the 
case of guard unwrapping [weak self] in closures. I've taken to creating an 
alternate self (guard let ss = self else { return }) constant and using that. 
But it always felt inelegant. The proposed case works without falling prey to 
the protection against redefining self that the compiler still needs to enforce 
and does it in a way that's clear and concise.  

Sent from my iPhone

> On Oct 31, 2016, at 6:46 PM, William Sumner via swift-evolution 
>  wrote:
> 
> 
>> On Oct 31, 2016, at 3:44 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> An alternative that would seem to satisfy some objections is to have a 
>>> distinct "unwrap" statement--as in: "unwrap x else { ... }".
>> 
>> I'd be against this alternative as it is doing the work of a guard statement 
>> (including the "must exit scope" rule) with a new keyword and unneeded 
>> redundancy.
>> 
>> Adding "unwrap" is local. It performs one very common task with added safety 
>> (avoids unintended shadow effects) and introduces succinctness and clarity. 
>> In other words, it is a highly focused changed with a measurable benefit in 
>> use.
>> 
>> Compare:
>> 
>> * "Introduce the unwrap statement that acts like guard but is limited to 
>> optionals" creates unnecessary language verbosity.
>> 
>> * "guard x else ", meaning "treat optional values differently than all other 
>> items in a conditional list", fails because it obscures rather than adds 
>> intent. Worse, it would lead to issues with Boolean optionals whose wrapped 
>> value is later used within the same condition.
>> 
>> Xiaodi, you mentioned an alternative approach and I'd love a peek at what 
>> that is.
>> 
>> — Erica
> 
> Your proposed form of unwrap naturally works in multiple places with clear 
> readability:
> 
> var foo: Any?
> if unwrap foo {}
> 
> while unwrap foo {}
> 
> guard unwrap foo else { return }
> 
> Preston
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[David Goodine via swift-evolution]

-1 as well, particularly agreeing with Rimantas that removing something of use 
because it confuses new programmers is not a good motivation.  To paraphrase 
Einstein, “A programming language should be as simple as possible, but no 
simpler.”

-d

> On Oct 26, 2016, at 6:26 AM, Rimantas Liubertas via swift-evolution 
>  wrote:
> 
> Pitch: I'd like to simplify the syntax, compiler complexity and learning 
> curve for newcomers when it comes to dealing with the ternary function. The 
> best way to do that, in my opinion, is to remove it entirely and add a new 
> function with better semantics that takes care of ternary operations entirely 
> within the Swift language.
> 
> -1
> 
> A lot of things can and will be confusing for newcomers, that's not the 
> reason to remove them. Being a newbie is a transitional state.
> OTOH, I've never got why ternary is considered especially confusing, for me 
> it never was a problem and I love the terseness of it.
> Only total novices in programming may be surprised by it, but they will be 
> suprised by a lot of things anyway, so ternary is the least of their 
> problems. Those with experiene in other languages will be most likely already 
> familiar with the
> operator.
> Also, many come to Swift from Objective C, which not only has ternary, but 
> also supports a variant where you can use it kind of like ?? in Swift: 
> NSString *other = someString ?: @"default string".
> 
> Removing ?: gains nothing and loses a lot, I'd say.
> 
> Best regards,
> Rimantas
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] guard let x = x

[David Goodine via swift-evolution]

Hey all,

As usual, apologies if this horse was beaten ages ago before I joined the 
mailing list, but thought I would bring this up.

I was typing the above (for the hundredth time) the other day and I was 
wondering whether it might be worth considering offering a shorter syntax:

guard let x, y, z else {…}

I was never convinced why implicit nil checks (i.e. if x {…}) were such a bad 
thing.  But now in Swift it seems that it would be much more convenient to be 
able to simply skip the assignment part of the expression and define the above 
as guaranteeing and unwrapping x, y and z in the appropriate scope.

I think with such powerful and already compact expressions now wanting to get 
on the same line,adding this would make the language even more compact and 
elegant.  It could be added as a non-source-breaking change, still allowing x = 
x for those who prefer it, but could significantly tighten up such uses, which 
I’m finding are ubiquitous in my code.

Any thoughts?

-d

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