My personal beef with leading-dot syntax


(Dave Abrahams) #1

on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:

Can you ping me off-list or in another thread and explain what the
issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me. I admit this is very
  personal/subjective.

* There is some evidence that people think it means something it doesn't
  (“enum case”), as mentioned in SE-0036. That suggests it is a
  confusing feature. That confusion may be fairly harmless so far, but
  still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
  to the language; why not just let those names be looked up without the
  dot? You can always disambiguate with full qualification if you have
  to.

* Static members generally are too verbose to access from within members
  of a type (`Self.x` doesn't work; you have to write out
  `TheFullTypeName.x`), and leading-dot doesn't give the ability to do
  so. If we're going to have a special syntax for accessing static
  members, it should *at least* solve this problem.

···

--
Dave


(Joe Groff) #2

Making every unqualified reference context-dependent would be impractical. `foo.bar(bas)` would become an exponential search to find a contextual type containing a `foo` which has a `bar` member that can accept an type containing a `bas` member.

-Joe

···

On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:

Can you ping me off-list or in another thread and explain what the
issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me. I admit this is very
personal/subjective.

* There is some evidence that people think it means something it doesn't
(“enum case”), as mentioned in SE-0036. That suggests it is a
confusing feature. That confusion may be fairly harmless so far, but
still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
to the language; why not just let those names be looked up without the
dot? You can always disambiguate with full qualification if you have
to.


(Erica Sadun) #3

on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:

Can you ping me off-list or in another thread and explain what the
issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me. I admit this is very
personal/subjective.

Indeed.

* There is some evidence that people think it means something it doesn't
(“enum case”), as mentioned in SE-0036. That suggests it is a
confusing feature. That confusion may be fairly harmless so far, but
still.

Noted.

* The dot doesn't seem to buy enough to be worth the complexity it adds
to the language; why not just let those names be looked up without the
dot? You can always disambiguate with full qualification if you have
to.

I kind of like the enumeration looking like an enumeration but I get your point.

* Static members generally are too verbose to access from within members
of a type (`Self.x` doesn't work; you have to write out
`TheFullTypeName.x`), and leading-dot doesn't give the ability to do
so. If we're going to have a special syntax for accessing static
members, it should *at least* solve this problem.

Just happened to start a thread a little while ago:
http://thread.gmane.org/gmane.comp.lang.swift.evolution/13708

-- E

···

On Apr 4, 2016, at 12:05 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:


(David Waite) #4

I believe the confusion comes from language references only using the leading dot to access enumerated values, and not to access an option set implementation or something like UIColor.

I can’t speak to the compiler processing impact or language impact of potential conflicts of looking these up without the leading dot. I can see how it would be confusing for people to have a very terse syntax for looking up static members on *other* types, and expecting either that same terse syntax or something comparable for referring to static members on their *own* type. Such syntax would have to tread softly on distinguishing static vs dynamic type resolution for looking up said members.

-DW

···

On Apr 4, 2016, at 12:05 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

* There is some evidence that people think it means something it doesn't
(“enum case”), as mentioned in SE-0036. That suggests it is a
confusing feature. That confusion may be fairly harmless so far, but
still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
to the language; why not just let those names be looked up without the
dot? You can always disambiguate with full qualification if you have
to.

* Static members generally are too verbose to access from within members
of a type (`Self.x` doesn't work; you have to write out
`TheFullTypeName.x`), and leading-dot doesn't give the ability to do
so. If we're going to have a special syntax for accessing static
members, it should *at least* solve this problem.


(Radek Pietruszewski) #5

As others noted:

* the ability to say .min, .max, .blackColor(), etc is extremely useful. Swift would be a lot worse off if only enum cases got their enum types inferred, and for any other static member of a type I would have type the fully qualified name
* the leading dot disambiguates the reference for the compiler **and for the reader**. I don’t have to guess if I’m not referencing something local, or explicitly disambiguate when needed. I just say, “.foo”, and it’s clear.
* I disagree that the rules of lookup are confusing. The feature is poorly documented in official guides, but it seems pretty straightforward to me. For any context implying T, .foo means a static member T.foo. Like you said, could be subjective ¯\_(ツ)_/¯

Best,
— Radek

···

On 04 Apr 2016, at 20:05, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:

Can you ping me off-list or in another thread and explain what the
issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me. I admit this is very
personal/subjective.

* There is some evidence that people think it means something it doesn't
(“enum case”), as mentioned in SE-0036. That suggests it is a
confusing feature. That confusion may be fairly harmless so far, but
still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
to the language; why not just let those names be looked up without the
dot? You can always disambiguate with full qualification if you have
to.

* Static members generally are too verbose to access from within members
of a type (`Self.x` doesn't work; you have to write out
`TheFullTypeName.x`), and leading-dot doesn't give the ability to do
so. If we're going to have a special syntax for accessing static
members, it should *at least* solve this problem.

--
Dave

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


Inconsistency in Type Inference?
(Dave Abrahams) #6

I don't think I'm talking about making every unqualified reference
context-dependent. When I have a context that demands an instance of a
particular enum type, I think it's reasonable to look up the names in
the enum without qualification, and I strongly question the value of
leading-dot syntax for general static member lookup. I would normally
never think of using it that way—because, guess what? I think of
leading-dot as a notation for enums like everybody else does—and I don't
think there are any important idioms it supports, that couldn't be
equally well handled by something like `Self.x` if we were allowed to
use it.

···

on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:

Can you ping me off-list or in another thread and explain what the
issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me. I admit this is very
personal/subjective.

* There is some evidence that people think it means something it doesn't
(“enum case”), as mentioned in SE-0036. That suggests it is a
confusing feature. That confusion may be fairly harmless so far, but
still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
to the language; why not just let those names be looked up without the
dot? You can always disambiguate with full qualification if you have
to.

Making every unqualified reference context-dependent would be
impractical. `foo.bar(bas)` would become an exponential search to find
a contextual type containing a `foo` which has a `bar` member that can
accept an type containing a `bas` member.

--
Dave


(Jordan Rose) #7

I strongly agree with all of these points, especially the second.

Jordan

···

On Apr 5, 2016, at 0:55 , Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

As others noted:

* the ability to say .min, .max, .blackColor(), etc is extremely useful. Swift would be a lot worse off if only enum cases got their enum types inferred, and for any other static member of a type I would have type the fully qualified name
* the leading dot disambiguates the reference for the compiler **and for the reader**. I don’t have to guess if I’m not referencing something local, or explicitly disambiguate when needed. I just say, “.foo”, and it’s clear.
* I disagree that the rules of lookup are confusing. The feature is poorly documented in official guides, but it seems pretty straightforward to me. For any context implying T, .foo means a static member T.foo. Like you said, could be subjective ¯\_(ツ)_/¯


(Joe Groff) #8

on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:

Can you ping me off-list or in another thread and explain what the
issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me. I admit this is very
personal/subjective.

* There is some evidence that people think it means something it doesn't
(“enum case”), as mentioned in SE-0036. That suggests it is a
confusing feature. That confusion may be fairly harmless so far, but
still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
to the language; why not just let those names be looked up without the
dot? You can always disambiguate with full qualification if you have
to.

Making every unqualified reference context-dependent would be
impractical. `foo.bar(bas)` would become an exponential search to find
a contextual type containing a `foo` which has a `bar` member that can
accept an type containing a `bas` member.

I don't think I'm talking about making every unqualified reference
context-dependent. When I have a context that demands an instance of a
particular enum type, I think it's reasonable to look up the names in
the enum without qualification, and I strongly question the value of
leading-dot syntax for general static member lookup.

Therein lies the rub—*any* context an unqualified name can appear in could potentially demand an instance of a particular enum type, until the type checker rules that out. Limiting the behavior to enums doesn't simplify the implementation.

I would normally
never think of using it that way—because, guess what? I think of
leading-dot as a notation for enums like everybody else does—and I don't
think there are any important idioms it supports, that couldn't be
equally well handled by something like `Self.x` if we were allowed to
use it.

Enums are only the most common place where static members of Self type appear in numbers, but option sets also do. While this may be a matter of taste, being able to refer to `.max`, `.infinity`, `.nan`, or other abstract constants of numeric types in a concrete-type-agnostic way also seems like a win to me.

-Joe

···

On Apr 4, 2016, at 11:44 AM, Dave Abrahams <dabrahams@apple.com> wrote:
on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:


(Brent Royal-Gordon) #9

When I have a context that demands an instance of a
particular enum type, I think it's reasonable to look up the names in
the enum without qualification, and I strongly question the value of
leading-dot syntax for general static member lookup. I would normally
never think of using it that way—because, guess what? I think of
leading-dot as a notation for enums like everybody else does—and I don't
think there are any important idioms it supports, that couldn't be
equally well handled by something like `Self.x` if we were allowed to
use it.

Well, sure, they don't know that leading dot is more widely usable—"The Swift Programming Language" only mentions it in connection with enums. But once people know, they're very glad to use it.

I've introduced several different people to the joys of universal leading-dot syntax, and I would characterize their reaction as *pleasant* surprise. They immediately start using the syntax for things like `.blackColor()` and `.passRetained(_:)` and `.min`, and often expand their usage beyond that. Now that unbound methods are uncurried, a small tweak to the leading dot syntax in function context will also open us up to things like `views.forEach(.removeFromSuperview)`. Lens functions may also eventually be used in this way.

If the feature is underused, that's because it's poorly explained, not because it's not widely desired.

(Besides, you probably at least use the syntax for option sets, which are enum-like but not enums.)

···

--
Brent Royal-Gordon
Architechies


(Chris Lattner) #10

+1 to all these points. Also, in Swift 3, “.blackColor()” becomes “.black()”.

-Chris

···

On Apr 6, 2016, at 9:27 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 5, 2016, at 0:55 , Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

As others noted:

* the ability to say .min, .max, .blackColor(), etc is extremely useful. Swift would be a lot worse off if only enum cases got their enum types inferred, and for any other static member of a type I would have type the fully qualified name
* the leading dot disambiguates the reference for the compiler **and for the reader**. I don’t have to guess if I’m not referencing something local, or explicitly disambiguate when needed. I just say, “.foo”, and it’s clear.
* I disagree that the rules of lookup are confusing. The feature is poorly documented in official guides, but it seems pretty straightforward to me. For any context implying T, .foo means a static member T.foo. Like you said, could be subjective ¯\_(ツ)_/¯

I strongly agree with all of these points, especially the second.


(Dave Abrahams) #11

on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:

Can you ping me off-list or in another thread and explain what the
issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me. I admit this is very
personal/subjective.

* There is some evidence that people think it means something it doesn't
(“enum case”), as mentioned in SE-0036. That suggests it is a
confusing feature. That confusion may be fairly harmless so far, but
still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
to the language; why not just let those names be looked up without the
dot? You can always disambiguate with full qualification if you have
to.

Making every unqualified reference context-dependent would be
impractical. `foo.bar(bas)` would become an exponential search to find
a contextual type containing a `foo` which has a `bar` member that can
accept an type containing a `bas` member.

I don't think I'm talking about making every unqualified reference
context-dependent. When I have a context that demands an instance of a
particular enum type, I think it's reasonable to look up the names in
the enum without qualification, and I strongly question the value of
leading-dot syntax for general static member lookup.

Therein lies the rub—*any* context an unqualified name can appear in
could potentially demand an instance of a particular enum type, until
the type checker rules that out. Limiting the behavior to enums
doesn't simplify the implementation.

I'm afraid I don't understand how that's a serious problem yet.

I would normally
never think of using it that way—because, guess what? I think of
leading-dot as a notation for enums like everybody else does—and I don't
think there are any important idioms it supports, that couldn't be
equally well handled by something like `Self.x` if we were allowed to
use it.

Enums are only the most common place where static members of Self type
appear in numbers, but option sets also do. While this may be a matter
of taste, being able to refer to `.max`, `.infinity`, `.nan`, or other
abstract constants of numeric types in a concrete-type-agnostic way
also seems like a win to me.

Agreed. Let me ask the question differently: what value does the
leading `.` provide to the user of the language?

···

on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On Apr 4, 2016, at 11:44 AM, Dave Abrahams <dabrahams@apple.com> wrote:
on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

--
Dave


(Joe Groff) #12

Right now, we limit the contextual lookup to places where it's syntactically asked for, using the leading dot. Without the leading dot, we'd have to extend it to every unqualified name, which makes it much more likely you'll fall into problematic cases.

-Joe

···

On Apr 4, 2016, at 12:51 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On Apr 4, 2016, at 11:44 AM, Dave Abrahams <dabrahams@apple.com> wrote:

on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:

Can you ping me off-list or in another thread and explain what the
issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me. I admit this is very
personal/subjective.

* There is some evidence that people think it means something it doesn't
(“enum case”), as mentioned in SE-0036. That suggests it is a
confusing feature. That confusion may be fairly harmless so far, but
still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
to the language; why not just let those names be looked up without the
dot? You can always disambiguate with full qualification if you have
to.

Making every unqualified reference context-dependent would be
impractical. `foo.bar(bas)` would become an exponential search to find
a contextual type containing a `foo` which has a `bar` member that can
accept an type containing a `bas` member.

I don't think I'm talking about making every unqualified reference
context-dependent. When I have a context that demands an instance of a
particular enum type, I think it's reasonable to look up the names in
the enum without qualification, and I strongly question the value of
leading-dot syntax for general static member lookup.

Therein lies the rub—*any* context an unqualified name can appear in
could potentially demand an instance of a particular enum type, until
the type checker rules that out. Limiting the behavior to enums
doesn't simplify the implementation.

I'm afraid I don't understand how that's a serious problem yet.


(E. Maloney) #13

Agreed. Let me ask the question differently: what value does the
leading `.` provide to the user of the language?

I find the leading-dot syntax to be very useful; it's a pretty clear shorthand that I'm not referencing something at global scope.

Here's a common example from our codebase:

completion(.Failed(.wrap(error)))

The completion function takes an enum value of type DataTransactionResult, of which .Failed is one case. The .Failed case takes an associated value of type DataTransactionError, which has a static function called wrap() that accepts an ErrorType and returns a DataTransactionError containing it.

Although .Failed is being used here in the common enum shorthand style, being able to very quickly determine that wrap() is not a global function is helpful. Without the leading dot, some context disappears:

completion(Failed(wrap(error)))

Now, it's a lot harder to tell what I'm dealing with.

What is 'Failed'? Is it a class with an initializer that we're passing the result of wrap(error) to? Or is it an enum case with an associated type? Further, what's wrap()? A function in the global scope? Sure looks like it!

If we got rid of the shorthand altogether, we end up with something much more verbose:

completion(DataTransactionResult.Failed(DataTransactionError.wrap(error)))

Yes, it's more explicit, but I would not necessarily argue that it's easier to read.


(Dave Abrahams) #14

I don't know how to evaluate whether that likelihood is a problem in
practice, or not, though.

···

on Mon Apr 04 2016, Joe Groff <swift-evolution@swift.org> wrote:

On Apr 4, 2016, at 12:51 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On Apr 4, 2016, at 11:44 AM, Dave Abrahams <dabrahams@apple.com> wrote:

on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:

On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:

Can you ping me off-list or in another thread and explain what the
issues are?

All of the following make me uncomfortable with our leading-dot thang:

* The rules for lookup don't seem obvious to me. I admit this is very
personal/subjective.

* There is some evidence that people think it means something it doesn't
(“enum case”), as mentioned in SE-0036. That suggests it is a
confusing feature. That confusion may be fairly harmless so far, but
still.

* The dot doesn't seem to buy enough to be worth the complexity it adds
to the language; why not just let those names be looked up without the
dot? You can always disambiguate with full qualification if you have
to.

Making every unqualified reference context-dependent would be
impractical. `foo.bar(bas)` would become an exponential search to find
a contextual type containing a `foo` which has a `bar` member that can
accept an type containing a `bas` member.

I don't think I'm talking about making every unqualified reference
context-dependent. When I have a context that demands an instance of a
particular enum type, I think it's reasonable to look up the names in
the enum without qualification, and I strongly question the value of
leading-dot syntax for general static member lookup.

Therein lies the rub—*any* context an unqualified name can appear in
could potentially demand an instance of a particular enum type, until
the type checker rules that out. Limiting the behavior to enums
doesn't simplify the implementation.

I'm afraid I don't understand how that's a serious problem yet.

Right now, we limit the contextual lookup to places where it's
syntactically asked for, using the leading dot. Without the leading
dot, we'd have to extend it to every unqualified name, which makes it
much more likely you'll fall into problematic cases.

--
Dave


(Howard Lovatt) #15

Moving away from the compiler, I like the leading dot for the programmer to
distinguish static and instance members. The 'missing' receiver natural
means static to me.

···

On Tuesday, 5 April 2016, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Joe Groff <swift-evolution@swift.org <javascript:;>> > wrote:

>> On Apr 4, 2016, at 12:51 PM, Dave Abrahams <dabrahams@apple.com > <javascript:;>> wrote:
>>
>>
>> on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:
>>
>
>>>> On Apr 4, 2016, at 11:44 AM, Dave Abrahams <dabrahams@apple.com > <javascript:;>> wrote:
>>>>
>>>>
>>>> on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:
>>>>
>>>
>>>>>> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org <javascript:;>> wrote:
>>>>>>
>>>>>>
>>>>>> on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org
<javascript:;>> asked:
>>>>>>
>>>>>
>>>>>>> Can you ping me off-list or in another thread and explain what the
>>>>>>> issues are?
>>>>>>
>>>>>> All of the following make me uncomfortable with our leading-dot
thang:
>>>>>>
>>>>>> * The rules for lookup don't seem obvious to me. I admit this is
very
>>>>>> personal/subjective.
>>>>>>
>>>>>> * There is some evidence that people think it means something it
doesn't
>>>>>> (“enum case”), as mentioned in SE-0036. That suggests it is a
>>>>>> confusing feature. That confusion may be fairly harmless so far,
but
>>>>>> still.
>>>>>>
>>>>>> * The dot doesn't seem to buy enough to be worth the complexity it
adds
>>>>>> to the language; why not just let those names be looked up without
the
>>>>>> dot? You can always disambiguate with full qualification if you
have
>>>>>> to.
>>>>>
>>>>> Making every unqualified reference context-dependent would be
>>>>> impractical. `foo.bar(bas)` would become an exponential search to
find
>>>>> a contextual type containing a `foo` which has a `bar` member that
can
>>>>> accept an type containing a `bas` member.
>>>>
>>>> I don't think I'm talking about making every unqualified reference
>>>> context-dependent. When I have a context that demands an instance of
a
>>>> particular enum type, I think it's reasonable to look up the names in
>>>> the enum without qualification, and I strongly question the value of
>>>> leading-dot syntax for general static member lookup.
>>>
>>> Therein lies the rub—*any* context an unqualified name can appear in
>>> could potentially demand an instance of a particular enum type, until
>>> the type checker rules that out. Limiting the behavior to enums
>>> doesn't simplify the implementation.
>>
>> I'm afraid I don't understand how that's a serious problem yet.
>
> Right now, we limit the contextual lookup to places where it's
> syntactically asked for, using the leading dot. Without the leading
> dot, we'd have to extend it to every unqualified name, which makes it
> much more likely you'll fall into problematic cases.

I don't know how to evaluate whether that likelihood is a problem in
practice, or not, though.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.


(Joe Groff) #16

I don't see any reason for a split here. Enum cases *are* static members, they just happen to be the ones people encounter most often.

-Joe

···

On Apr 4, 2016, at 6:27 PM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

Is a solution to this actually making the leading dot mean enum lookup, full stop and allowing `Self.foo`? The case that that doesn't cover is static members on a type other than `Self`. I use it to great effect for standard instances of types, so I would appreciate *some* facility to provide that, but it doesn't have to be a leading dot if we can think of a way which is less problematic.

I am simply spitballing here but would
1 period for enum look up
2 periods for static member lookup

or something similar be a solution? It doesn't use another character or keyword and it makes it clear which feature is being used.


(Brent Royal-Gordon) #17

Because semantically they seem more like types unto themselves

But they aren't types.

* You can't declare a variable/property/parameter of a particular case.
* You can't constrain a generic type parameter to a case.
* You can't cast to a case with `as` and friends or test for a case with `is`.
* You can't conform different cases to different protocols.
* You can't give different cases different members. (The associated value tuple is not a member; you can only access it with pattern matching.)

There is nothing subtle or ambiguous about this. Swift does not even blur the line anywhere, except in the switch statement (which is full of ad-hoc magic) and in the now-corrected capitalization convention. Cases simply *are not* types. They are different values which may be stored in the same type, just as `Int(1)` and `Int(2)` are not different types.

···

--
Brent Royal-Gordon
Architechies


(TJ Usiyan) #18

Is a solution to this actually making the leading dot mean enum lookup,
full stop and allowing `Self.foo`? The case that that doesn't cover is
static members on a type other than `Self`. I use it to great effect for
standard instances of types, so I would appreciate *some* facility to
provide that, but it doesn't have to be a leading dot if we can think of a
way which is less problematic.

I am simply spitballing here but would
1 period for enum look up
2 periods for static member lookup

or something similar be a solution? It doesn't use another character or
keyword and it makes it clear which feature is being used.

TJ

···

On Mon, Apr 4, 2016 at 4:22 PM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote:

Moving away from the compiler, I like the leading dot for the programmer
to distinguish static and instance members. The 'missing' receiver natural
means static to me.

On Tuesday, 5 April 2016, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Mon Apr 04 2016, Joe Groff <swift-evolution@swift.org> wrote:

>> On Apr 4, 2016, at 12:51 PM, Dave Abrahams <dabrahams@apple.com> >> wrote:
>>
>>
>> on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:
>>
>
>>>> On Apr 4, 2016, at 11:44 AM, Dave Abrahams <dabrahams@apple.com> >> wrote:
>>>>
>>>>
>>>> on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:
>>>>
>>>
>>>>>> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:
>>>>>>
>>>>>>
>>>>>> on Mon Apr 04 2016, Erica Sadun <swift-evolution@swift.org> asked:
>>>>>>
>>>>>
>>>>>>> Can you ping me off-list or in another thread and explain what the
>>>>>>> issues are?
>>>>>>
>>>>>> All of the following make me uncomfortable with our leading-dot
thang:
>>>>>>
>>>>>> * The rules for lookup don't seem obvious to me. I admit this is
very
>>>>>> personal/subjective.
>>>>>>
>>>>>> * There is some evidence that people think it means something it
doesn't
>>>>>> (“enum case”), as mentioned in SE-0036. That suggests it is a
>>>>>> confusing feature. That confusion may be fairly harmless so far,
but
>>>>>> still.
>>>>>>
>>>>>> * The dot doesn't seem to buy enough to be worth the complexity it
adds
>>>>>> to the language; why not just let those names be looked up without
the
>>>>>> dot? You can always disambiguate with full qualification if you
have
>>>>>> to.
>>>>>
>>>>> Making every unqualified reference context-dependent would be
>>>>> impractical. `foo.bar(bas)` would become an exponential search to
find
>>>>> a contextual type containing a `foo` which has a `bar` member that
can
>>>>> accept an type containing a `bas` member.
>>>>
>>>> I don't think I'm talking about making every unqualified reference
>>>> context-dependent. When I have a context that demands an instance
of a
>>>> particular enum type, I think it's reasonable to look up the names in
>>>> the enum without qualification, and I strongly question the value of
>>>> leading-dot syntax for general static member lookup.
>>>
>>> Therein lies the rub—*any* context an unqualified name can appear in
>>> could potentially demand an instance of a particular enum type, until
>>> the type checker rules that out. Limiting the behavior to enums
>>> doesn't simplify the implementation.
>>
>> I'm afraid I don't understand how that's a serious problem yet.
>
> Right now, we limit the contextual lookup to places where it's
> syntactically asked for, using the leading dot. Without the leading
> dot, we'd have to extend it to every unqualified name, which makes it
> much more likely you'll fall into problematic cases.

I don't know how to evaluate whether that likelihood is a problem in
practice, or not, though.

--
Dave

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

--
-- Howard.

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


(TJ Usiyan) #19

Because semantically they seem more like types unto themselves–which is why
I disagree with the lower camel casing but I digress–and the fact that they
are static members seems like an implementation detail more than anything
else.

TJ

···

On Mon, Apr 4, 2016 at 10:15 PM, Joe Groff <jgroff@apple.com> wrote:

> On Apr 4, 2016, at 6:27 PM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Is a solution to this actually making the leading dot mean enum lookup,
full stop and allowing `Self.foo`? The case that that doesn't cover is
static members on a type other than `Self`. I use it to great effect for
standard instances of types, so I would appreciate *some* facility to
provide that, but it doesn't have to be a leading dot if we can think of a
way which is less problematic.
>
> I am simply spitballing here but would
> 1 period for enum look up
> 2 periods for static member lookup
>
> or something similar be a solution? It doesn't use another character or
keyword and it makes it clear which feature is being used.

I don't see any reason for a split here. Enum cases *are* static members,
they just happen to be the ones people encounter most often.

-Joe


(TJ Usiyan) #20

*like* types. I, at no point, said that they are types.

Pointing out what they can't do is not a great stance, in my opinion,
because some of those things are perfectly reasonable but simply might not
have been considered or attempted yet. I am *not* arguing that they are
types. I am arguing that they are semantically different from static
members. If they aren't, why not simply give us a means to pattern match
over custom values and call it a day?

My point is that enum are special.

enum Boolean {
    case True, False
}

We could argue that `True` and `False` are just instances of Boolean. I
will argue that you provide no significant state (Void) in either case to
'create' or 'choose' either `True` or `False`. You provide such a raw
value to `Int` to create each instance but you do no such thing for an
enum without an associate value. You do, however, provide a significant bit
of state to enums with associated values. Both the case choses AND the
state define identity, which places it between an enum without associated
values and a struct/class/product type

enum Optional<T> {
    case Some(T)
    case None
}

Again, I agree that they are not types. I disagree that they are just like
`Int` Each case is a signifier between member value and type.
TJ

···

On Mon, Apr 4, 2016 at 11:04 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

> Because semantically they seem more like types unto themselves

But they aren't types.

* You can't declare a variable/property/parameter of a particular case.
* You can't constrain a generic type parameter to a case.
* You can't cast to a case with `as` and friends or test for a case with
`is`.
* You can't conform different cases to different protocols.
* You can't give different cases different members. (The associated value
tuple is not a member; you can only access it with pattern matching.)

There is nothing subtle or ambiguous about this. Swift does not even blur
the line anywhere, except in the switch statement (which is full of ad-hoc
magic) and in the now-corrected capitalization convention. Cases simply
*are not* types. They are different values which may be stored in the same
type, just as `Int(1)` and `Int(2)` are not different types.

--
Brent Royal-Gordon
Architechies