We should add an unless one to compliement it :)
unless foo?
{
}
On Wed, Jan 6, 2016 at 6:16 AM, Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:
> +1
>
> Type narrowing would also fit nicely with union types (as demonstrated in
> Ceylon).
>
> -Thorsten
>
> Am 05.01.2016 um
+1
Type narrowing would also fit nicely with union types (as demonstrated in
Ceylon).
-Thorsten
> Am 05.01.2016 um 23:37 schrieb Dennis Lysenko :
>
> That said, I am in favor of automatic type narrowing. As long as it doesn't
> complicate the compiler considerably (if it does, there's little
That said, I am in favor of automatic type narrowing. As long as it doesn't
complicate the compiler considerably (if it does, there's little reason to
replace optional binding), it's no less confusing than shadowing was when I
first saw it, and once you get used to it (shouldn't be more than a day)
Thorsten,
Not that I disapprove (Kotlin does the same and it's great), the precedent
seems to have already been set in people's minds that there won't be any
kind of implicit type narrowing and I predict a fair few will respond with
"You can already do that with optional binding, and I'm uncomfort
Ceylon has type narrowing (not only for optional unwrapping but for type checks
as well):
http://ceylon-lang.org/documentation/1.2/tour/types/#narrowing_the_type_of_an_object_reference
It always struck me as quite natural to do this.
-Thorsten
> Am 02.01.2016 um 06:08 schrieb Tyler Fleming Clo
Whoops, errant button tap.
I've always thought that,
if let foo = foo? {
}
makes more sense than
if let foo = foo {
}
as the ? indicates that you are unwrapping the optional and then assigning it
to the new variable.
The current syntax must seem incomprehensible/redundant to those new t
I've always thought that,
if let foo = foo? {
}
makes more sense than
if let foo = foo {
}
as the ? indicates that you are unwrapping the optional and then assigning it
to the new variable
> On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution
> wrote:
>
> I’ve only read the l
> let color : Color? = getFavoriteColor()
> if color != nil {
> // Color is no longer an Optional
> }
well, I'd just write
if let color = getFavoriteColor() {…
This even more as the other solutions hide that "color" isn't the original
"color" anymore inside the braces:
The first one was an
This is problematic for anything other than 'let', since the value could change
/ be changed while inside the block. And I wouldn't want to give 'let' special
privileges here.
Jordan
> On Dec 21, 2015, at 18:36 , Kyle Carson via swift-evolution
> wrote:
>
> I've got another solution. It's s
I've got another solution. It's simple and very "swift". The code "var !=
nil" can be used as a hint to the compiler that *var* is not an optional.
Code example:
let color : Color? = getFavoriteColor()
if color != nil {
// Color is no longer an Optional
}
_
One question first: Have you thought of user trying to do
let object.someProperty
?
The syntax looks like a nice shortcut at the first glance, but we shouldn't
forget that there is already a different shortcut involved in many of those
assignments:
self.foo...
> But, “if let foo = foo {}” makes
@Kevin: That is why I'm suggesting if unwrap foo {, because I believe it's
clearer than either. I was trying to say, though, that "if let foo = bar",
one of the first things you learn in swift, transitions naturally to "if
let foo = foo", though slightly disorienting at first, but will be
disconnec
> However, you may be interested in the last email Chris sent in this chain
> with regards to shortening it to just "let foo":
>
> "This is commonly requested - the problem is that while it does help reduce
> boilerplate, it runs counter to the goal of improving clarity."
>
> He's got a point;
> On Dec 19, 2015, at 5:12 PM, Dennis Lysenko via swift-evolution
> wrote:
>
> Cihat, if either of the two you proposed I would prefer "let foo?" as the
> bang (!), outside of logical negation, carries a meaning of "this is
> dangerous and something could go wrong at runtime here". Evidenced
Cihat, if either of the two you proposed I would prefer "let foo?" as the
bang (!), outside of logical negation, carries a meaning of "this is
dangerous and something could go wrong at runtime here". Evidenced by its
only other uses--try!, force-unwrapping, and implicitly unwrapped optionals.
Howe
I’ve only read the last couple of posts but has anybody already suggested using
something like this:
if let foo! {
// code that uses foo
}
People already know that the ! is unwrapping a value and that let is defining a
new constant. So why not combine those two?
Alternatively it could also be
> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution
> wrote:
>
> I was going to suggest something similar (a hard naming problem also):
>
> if has foo {
> // foo is now unwrapped and non-optional
> }
>
> guard has foo else { return }
>
> Does the same thing as `let
I was going to suggest something similar (a hard naming problem also):
if has foo {
// foo is now unwrapped and non-optional
}
guard has foo else { return }
Does the same thing as `let foo = foo` in practice, but places it in a somewhat
different mental model. Instead of unwrapping and imme
> On Dec 19, 2015, at 1:41 PM, Dennis Lysenko
> wrote:
>
> Shadowing is good in this case because it lets you capture constant values
> for the exact scope in which you need them.
>
That is completely independent of shadowing. You do that even if you choose
different names inside the block
> On Dec 19, 2015, at 1:37 PM, ilya wrote:
>
> I prefer
>
> if let vc = someInterestingViewConroller {
> vc.doSomething()
> }
>
> - Explicit is better than implicit
> - shadowing is bad
> - now there's no ambiguity about how to change the original property.
>
Creating a less descriptive
Another argument is in a large block with several bound optionals, reusing
names prevents people from accidentally accessing optionals that were
already bound to non optional values.
We were all skeptical, I think, of reusing names in optional binding at
first (I thought it looked ugly), but I gre
Shadowing is good in this case because it lets you capture constant values
for the exact scope in which you need them. This helps avoid overhead of
repeated getters and method calls. Using shorter names is automatically
less descriptive; otherwise, people would advocate using abbreviations in
prope
Disagree. Short names are less descriptive and less readable. And saying
"shadowing is bad" without any argument is just silly for a mailing list.
On Sat, Dec 19, 2015, 3:57 PM Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:
> On Dec 19, 2015, at 12:37 PM, ilya via swift-evo
> On Dec 19, 2015, at 12:37 PM, ilya via swift-evolution
> wrote:
>
> I prefer
>
> if let vc = someInterestingViewConroller {
> vc.doSomething()
> }
>
> - Explicit is better than implicit
> - shadowing is bad
> - now there's no ambiguity about how to change the original property.
>
> Th
I prefer
if let vc = someInterestingViewConroller {
vc.doSomething()
}
- Explicit is better than implicit
- shadowing is bad
- now there's no ambiguity about how to change the original property.
Therefore I'm -1 on any proposal that hides explicit name binding and/or
increases shadowing, includi
What if we made the keyword "unwrap"?
if unwrap someViewController {
// now there is a shadowing nonoptional (unwrapped) variable of the same
name only within this scope, boiling down to simple syntactic sugar for
optional binding and it is fairly clear.
}
On Sat, Dec 19, 2015, 1:31 PM Kevin Woot
As much fun as it to example with foo, I would argue the opposite when you use
some real world variable names:
if let someInterestingViewConroller = someInterestingViewConroller {
}
vs
If let someInterestingViewConroller {
}
We know what let does and it should be enough to impart the necessary
> On Dec 11, 2015, at 8:11 AM, Daniel Hooper via swift-evolution
> wrote:
>
> A very common pattern in swift code is to "guard let" or "if let" optionals
> - this works by creating a new non-optional variable to be used by future
> code. Often, the new variable is given the same name as the
> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution
> wrote:
>
> I’ve had similar ideas to this. Instead of ditching the if let syntax
> altogether, another approach would be to use the existing name if no new name
> is given, so that this code:
>
> if let foo = foo { /* use
29 matches
Mail list logo
