> On Jun 8, 2016, at 4:59 PM, Brandon Knope via swift-evolution
> wrote:
>
> Is it really an implementation detail? It is very leaky if it is one because
> it is highly exposed to everyone.
It’s only as leaky as you want it to be. We have two shipping apps with large
codebases using Swift, a
On Wed, Jun 08 2016 at 05:16:26 PM, Brandon Knope wrote:
>> On Jun 8, 2016, at 5:03 PM, Roth Michaels via swift-evolution
>> wrote:
>> Would you allow this?
>>
>> let myStrings = ["s1": "hello, world", "s2": "something else"]
>> myStrings["s2"] = .none
>>
>> If so, that would make this example
The same example won’t work in objective-c
number1 and number2 are two different variables that holds different values.
When you are assigning number2 = number1 you’re copying the value. And when you
are comparing number1 == number2 you are comparing values, that are the same
because one is a co
My objection to this is that .none is a fairly common member in various enums
(besides Optional) and it's a mess already:
enum EventDataRenderType {
case none
case tab
case blockClosed
case blockOpened
}
let data = self.data
if data.customization?.renderType == .n
Here I have a contrived example (I am bad at trying to explain my point -_-):
When I see nil, I think of reference types. I.e. Objective-C:
NSMutableString *mutableString = [[NSMutableString alloc]
initWithString:@"123"];
__weak NSMutableString *reference = mutableString;
reference = mutabl
I don't see a reason to rename or remove the `nil` literal.
But I can come up with a concrete reason to deprecate NilLiteralConvertible:
The language has made Optional a very specific thing with `if let` syntax,
implicit wrapping, and optional chaining to name a few. But the second most
common
When isn’t it?
l8r
Sean
> On Jun 8, 2016, at 4:22 PM, Brandon Knope wrote:
>
> Yes it is the same keyword, but is it the same behavior from other languages?
>
> Brandon
>
>> On Jun 8, 2016, at 5:20 PM, Saagar Jha wrote:
>>
>> I think we also need to consider newbies coming from other langu
> On Jun 8, 2016, at 5:03 PM, Roth Michaels via swift-evolution
> wrote:
>
>
>
>
> So are you proposing to disallow the following:
>
> let myStrings = ["s1": "hello, world", "s2": "something else"]
> myStrings["s2"] = nil
>
> Replacing it with the following:
>
> let myStrings = ["s1":
Yes it is the same keyword, but is it the same behavior from other languages?
Brandon
> On Jun 8, 2016, at 5:20 PM, Saagar Jha wrote:
>
> I think we also need to consider newbies coming from other languages. “nil”
> being a holdover makes it easier to understand what it means, having a
> “.no
I was thinking about this too…but I’m not sure how feasible it would be.
However, I don’t find this any more confusing than having two ways to refer to
it currently: nil and .none
none == sugar
.none == the underlying implementation of optional as Xiaodi put it (I am
starting to see this view)
I think we also need to consider newbies coming from other languages. “nil”
being a holdover makes it easier to understand what it means, having a
“.none”/“none” duality makes it both seem inconsistent as well as dredge up
language implementation details-now you have to explain that Optionals are
a
If there’s both “.none” and “none”, then I think that’d be more confusing
*because of* the naming consistency, IMO. I’d look at that as a newbie and
wonder why in the world this word sometimes has a dot and sometimes doesn’t.
If enum cases could be referred to without the leading “.” then perhap
Isn’t the only thing keeping nil relevant is the NilLiteralConvertible protocol?
Brandon
> On Jun 8, 2016, at 5:08 PM, John McCall via swift-evolution
> wrote:
>
>> On Jun 8, 2016, at 1:41 PM, Антон Жилин via swift-evolution
>> wrote:
>> (No joking)
>> Points:
>>
>> 1. When nil was added to
In my other thread where this came up, my support is:
1. Removing NilLiteralConvertible conformance from Optional (apparently other
people use this protocol?)
2. Introducing a new keyword that is sugar for .none
Would I like to remove nil and NilLiteralConvertible? Perhaps, but it seems
that som
> On Jun 8, 2016, at 1:41 PM, Антон Жилин via swift-evolution
> wrote:
> (No joking)
> Points:
>
> 1. When nil was added to the language, we could not infer enumeration type:
> if x != Optional.none { ... }
>
> Now it looks like this:
> if x != .none { ... }
>
> If at this point we had a propo
So are you proposing to disallow the following:
let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings["s2"] = nil
Replacing it with the following:
let myStrings = ["s1": "hello, world", "s2": "something else"]
myStrings.removeValueForKey("s2")
Thus subscript(_) could only
1. People will find .none ugly which is why I think it could be replaced by a
none keyword. It is awkward
2. none is more descriptive than nil in this case. The case is named none
(consistency!) and nil is a holdover from other languages
I understand how nil works in the context of other languag
On Wed, Jun 8, 2016 at 3:59 PM, Brandon Knope wrote:
> Is it really an implementation detail? It is very leaky if it is one
> because it is highly exposed to everyone.
>
> Regardless of whether or not it is an implementation detail, nil does not
> adequately describe the “none” case it is trying
Is it really an implementation detail? It is very leaky if it is one because it
is highly exposed to everyone.
Regardless of whether or not it is an implementation detail, nil does not
adequately describe the “none” case it is trying to represent in my opinion
B
> On Jun 8, 2016, at 4:56 PM,
On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope wrote:
> .none or a more appropriate keyword like “none” (imo)
>
>
My point is that `.none` exposes the underlying enum. The premise here is
that the enum is an implementation detail. You'll notice that, currently,
significant sugar and magic is devot
If you add a new keyword called “none” without the period, but keep allowing
“.none” to work because Optional is really an enum… then I don’t really see
what has been gained here at all - you’re basically back to nil/.none => 2 ways
to say the same thing!
l8r
Sean
> On Jun 8, 2016, at 3:52 PM
.none or a more appropriate keyword like “none” (imo)
Brandon
> On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution
> wrote:
>
> It's been pointed out before that Optional being an enum type is treated like
> an implementation detail. Currently, it is possible to teach the concept of
>
It's been pointed out before that Optional being an enum type is treated
like an implementation detail. Currently, it is possible to teach the
concept of Optional without introducing enum types or generics. How would
you do so after elimination of nil?
On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин
I think you know I am very +1 on this :)
Brandon
> On Jun 8, 2016, at 4:41 PM, Антон Жилин via swift-evolution
> wrote:
>
> (No joking)
> Points:
>
> 1. When nil was added to the language, we could not infer enumeration type:
> if x != Optional.none { ... }
>
> Now it looks like this:
> if x
(No joking)
Points:
1. When nil was added to the language, we could not infer enumeration type:
if x != Optional.none { ... }
Now it looks like this:
if x != .none { ... }
If at this point we had a proposal to add nil as a replacement for .none,
would we accept it?
2. nil is very generic, it on
25 matches
Mail list logo
