Fw: Re: [Proposal Draft] Literal Syntax Protocols

Evolution Discussion
1

I’m aware of that fact, but all types with underscore even in the stdlib telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but its declaration isn’t visible at all:

// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb

···

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew@anandabits.com) schrieb:

The underscore is used in the same way it is used elsewhere in the standard library. The protocols must be public because they need to be visible to user code in order for the design to work correctly. However, they are considered implementation details that users really shouldn’t know about. This pattern is well established in the standard library.

2

The design in this proposal comes from the standard library team. The intent is for the use of underscore here to be consistent with other uses of underscore prefix in the standard library. I’m not sure why you think this is different than the rest...

···

On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’m aware of that fact, but all types with underscore even in the stdlib telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but its declaration isn’t visible at all:
// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 <rdar://25214598> - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb <https://github.com/apple/swift/blob/63c36dff0a327874a5041d46335bde314bc108d8/stdlib/public/core/Stride.swift.gyb&gt;

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

The underscore is used in the same way it is used elsewhere in the standard library. The protocols must be public because they need to be visible to user code in order for the design to work correctly. However, they are considered implementation details that users really shouldn’t know about. This pattern is well established in the standard library.

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

3

Really? I must have overlooked that some pitched that design.

Okay now that I think through this whole scenario, I like the underscore iff there is a good name that will be present in the final version.

When Swift 3 drops, I’ll write a proposal for nested protocols which will refine your design (the original author went missing after pitching this idea, and Joe Groff told me that this probably out of scope for Swift 3)!

Your current design might become this in Swift 3.X and all protocols marked with an underscore will disappear:

public /* closed */ enum Syntax {
  public protocol NilLiteral { ... }
  public protocol BooleanLiteral { ... }
  public protocol IntegerLiteral { ... }
  public protocol FloatLiteral { ... }
  public protocol UnicodeScalarLiteral { ... }
  public protocol ExtendedGraphemeClusterLiteral { ... }
  public protocol StringLiteralLiteral { ... }
  public protocol StringInterplolationLiteral { ... }
  public protocol ArrayrLiteral { ... }
  public protocol DictionaryLiteral { ... }
}

···

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matthew@anandabits.com) schrieb:

The design in this proposal comes from the standard library team. The intent is for the use of underscore here to be consistent with other uses of underscore prefix in the standard library. I’m not sure why you think this is different than the rest...

On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’m aware of that fact, but all types with underscore even in the stdlib telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but its declaration isn’t visible at all:
// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew@anandabits.com) schrieb:

The underscore is used in the same way it is used elsewhere in the standard library. The protocols must be public because they need to be visible to user code in order for the design to work correctly. However, they are considered implementation details that users really shouldn’t know about. This pattern is well established in the standard library.

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

4

I find these 'stay-off-my-property' _ rather sub-par in a modern language (everything was different for c 40years ago). I find it rather sad to think that we r about to commit to using that pattern for another 30 years. If the demark between stdlib and compiler was cleaned up, it would even open the door to a clean way to make some embedded stdlib versions in the future
Regards
LM
(From mobile)

···

On Jun 24, 2016, at 5:22 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’m aware of that fact, but all types with underscore even in the stdlib telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but its declaration isn’t visible at all:

// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew@anandabits.com) schrieb:

The underscore is used in the same way it is used elsewhere in the standard library. The protocols must be public because they need to be visible to user code in order for the design to work correctly. However, they are considered implementation details that users really shouldn’t know about. This pattern is well established in the standard library.

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

5

Really? I must have overlooked that some pitched that design.

It wasn’t pitched in its own thread. It came up in discussions about the previous proposal a couple different times.

Okay now that I think through this whole scenario, I like the underscore iff there is a good name that will be present in the final version.

When Swift 3 drops, I’ll write a proposal for nested protocols which will refine your design (the original author went missing after pitching this idea, and Joe Groff told me that this probably out of scope for Swift 3)!

Yes, the plan is to take advantage of any relevant features Swift gets in the future. This would allow removal of the underscore protocols. If Swift gets submodules or real namespaces I’m sure `Syntax` would become one of those as well. The good news is that all of this is considered implementation details that don’t affect user code so I don’t believe making these changes would require a proposal.

···

On Jun 24, 2016, at 10:37 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
Your current design might become this in Swift 3.X and all protocols marked with an underscore will disappear:

public /* closed */ enum Syntax {
  public protocol NilLiteral { ... }
  public protocol BooleanLiteral { ... }
  public protocol IntegerLiteral { ... }
  public protocol FloatLiteral { ... }
  public protocol UnicodeScalarLiteral { ... }
  public protocol ExtendedGraphemeClusterLiteral { ... }
  public protocol StringLiteralLiteral { ... }
  public protocol StringInterplolationLiteral { ... }
  public protocol ArrayrLiteral { ... }
  public protocol DictionaryLiteral { ... }
}

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

The design in this proposal comes from the standard library team. The intent is for the use of underscore here to be consistent with other uses of underscore prefix in the standard library. I’m not sure why you think this is different than the rest...

On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I’m aware of that fact, but all types with underscore even in the stdlib telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but its declaration isn’t visible at all:
// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 <rdar://25214598> - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb <https://github.com/apple/swift/blob/63c36dff0a327874a5041d46335bde314bc108d8/stdlib/public/core/Stride.swift.gyb&gt;

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

The underscore is used in the same way it is used elsewhere in the standard library. The protocols must be public because they need to be visible to user code in order for the design to work correctly. However, they are considered implementation details that users really shouldn’t know about. This pattern is well established in the standard library.

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

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

6

That said, how about this design:

public protocol _LiteralNilProtocol { … }
…

public enum Literal {
     
    public typealias NilProtocol = …
    …
}
extension Array: Literal.ArrayProtocol

···

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:37:27, Adrian Zubarev (adrian.zubarev@devandartist.com) schrieb:

Really? I must have overlooked that some pitched that design.

Okay now that I think through this whole scenario, I like the underscore iff there is a good name that will be present in the final version.

When Swift 3 drops, I’ll write a proposal for nested protocols which will refine your design (the original author went missing after pitching this idea, and Joe Groff told me that this probably out of scope for Swift 3)!

Your current design might become this in Swift 3.X and all protocols marked with an underscore will disappear:

public /* closed */ enum Syntax {
  public protocol NilLiteral { ... }
  public protocol BooleanLiteral { ... }
  public protocol IntegerLiteral { ... }
  public protocol FloatLiteral { ... }
  public protocol UnicodeScalarLiteral { ... }
  public protocol ExtendedGraphemeClusterLiteral { ... }
  public protocol StringLiteralLiteral { ... }
  public protocol StringInterplolationLiteral { ... }
  public protocol ArrayrLiteral { ... }
  public protocol DictionaryLiteral { ... }
}

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matthew@anandabits.com) schrieb:

The design in this proposal comes from the standard library team. The intent is for the use of underscore here to be consistent with other uses of underscore prefix in the standard library. I’m not sure why you think this is different than the rest...

On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’m aware of that fact, but all types with underscore even in the stdlib telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but its declaration isn’t visible at all:
// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew@anandabits.com) schrieb:

The underscore is used in the same way it is used elsewhere in the standard library. The protocols must be public because they need to be visible to user code in order for the design to work correctly. However, they are considered implementation details that users really shouldn’t know about. This pattern is well established in the standard library.

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

7

That said, how about this design:

public protocol _LiteralNilProtocol { … }
…

public enum Literal {
     
    public typealias NilProtocol = …
    …
}

I’m pretty sure the standard library team intends to reserve the right to use this namespace for other protocols that only exist for syntactic support. This may not always be literals - there may be other kinds of syntax supporting protocols in the future. With that in mind I don’t think this design will work.

···

On Jun 24, 2016, at 10:41 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:
extension Array: Literal.ArrayProtocol

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:37:27, Adrian Zubarev (adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>) schrieb:

Really? I must have overlooked that some pitched that design.

Okay now that I think through this whole scenario, I like the underscore iff there is a good name that will be present in the final version.

When Swift 3 drops, I’ll write a proposal for nested protocols which will refine your design (the original author went missing after pitching this idea, and Joe Groff told me that this probably out of scope for Swift 3)!

Your current design might become this in Swift 3.X and all protocols marked with an underscore will disappear:

public /* closed */ enum Syntax {
  public protocol NilLiteral { ... }
  public protocol BooleanLiteral { ... }
  public protocol IntegerLiteral { ... }
  public protocol FloatLiteral { ... }
  public protocol UnicodeScalarLiteral { ... }
  public protocol ExtendedGraphemeClusterLiteral { ... }
  public protocol StringLiteralLiteral { ... }
  public protocol StringInterplolationLiteral { ... }
  public protocol ArrayrLiteral { ... }
  public protocol DictionaryLiteral { ... }
}

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

The design in this proposal comes from the standard library team. The intent is for the use of underscore here to be consistent with other uses of underscore prefix in the standard library. I’m not sure why you think this is different than the rest...

On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I’m aware of that fact, but all types with underscore even in the stdlib telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but its declaration isn’t visible at all:
// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 <rdar://25214598> - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb <https://github.com/apple/swift/blob/63c36dff0a327874a5041d46335bde314bc108d8/stdlib/public/core/Stride.swift.gyb&gt;

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

The underscore is used in the same way it is used elsewhere in the standard library. The protocols must be public because they need to be visible to user code in order for the design to work correctly. However, they are considered implementation details that users really shouldn’t know about. This pattern is well established in the standard library.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

8

That said, how about this design:

public protocol _LiteralNilProtocol { … }
…

public enum Literal {

    public typealias NilProtocol = …
    …
}

I’m pretty sure the standard library team intends to reserve the right to
use this namespace for other protocols that only exist for syntactic
support. This may not always be literals - there may be other kinds of
syntax supporting protocols in the future. With that in mind I don’t think
this design will work.

That said, `IntegerLiteralProtocol` or `Syntax.IntegerLiteralProtocol` both
read very nicely, IMO, so that aspect of the idea is worth considering.

···

On Fri, Jun 24, 2016 at 2:50 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

On Jun 24, 2016, at 10:41 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

extension Array: Literal.ArrayProtocol

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:37:27, Adrian Zubarev (
adrian.zubarev@devandartist.com) schrieb:

Really? I must have overlooked that some pitched that design.

Okay now that I think through this whole scenario, I like the underscore
iff there is a good name that will be present in the final version.

When Swift 3 drops, I’ll write a proposal for nested protocols which will
refine your design (the original author went missing after pitching this
idea, and Joe Groff told me that this probably out of scope for Swift 3)!

Your current design might become this in Swift 3.X and all protocols
marked with an underscore will disappear:

public /* closed */ enum Syntax {
  public protocol NilLiteral { ... }
  public protocol BooleanLiteral { ... }
  public protocol IntegerLiteral { ... }
  public protocol FloatLiteral { ... }
  public protocol UnicodeScalarLiteral { ... }
  public protocol ExtendedGraphemeClusterLiteral { ... }
  public protocol StringLiteralLiteral { ... }
  public protocol StringInterplolationLiteral { ... }
  public protocol ArrayrLiteral { ... }
  public protocol DictionaryLiteral { ... }
}

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matthew@anandabits.com)
schrieb:

The design in this proposal comes from the standard library team. The
intent is for the use of underscore here to be consistent with other uses
of underscore prefix in the standard library. I’m not sure why you think
this is different than the rest...

On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

I’m aware of that fact, but all types with underscore even in the stdlib
telling me to keep my hands of them, because something might happen to them.
As an example we have _Strideable protocol which is visible by its name,
but its declaration isn’t visible at all:

// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:

From Stride.swift.gyb
<https://github.com/apple/swift/blob/63c36dff0a327874a5041d46335bde314bc108d8/stdlib/public/core/Stride.swift.gyb&gt;

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew@anandabits.com)
schrieb:

The underscore is used in the same way it is used elsewhere in the
standard library. The protocols must be public because they need to be
visible to user code in order for the design to work correctly. However,
they are considered implementation details that users really shouldn’t know
about. This pattern is well established in the standard library.

_______________________________________________
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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

That said, how about this design:

public protocol _LiteralNilProtocol { … }
…

public enum Literal {
     
    public typealias NilProtocol = …
    …
}

I’m pretty sure the standard library team intends to reserve the right to use this namespace for other protocols that only exist for syntactic support. This may not always be literals - there may be other kinds of syntax supporting protocols in the future. With that in mind I don’t think this design will work.

That said, `IntegerLiteralProtocol` or `Syntax.IntegerLiteralProtocol` both read very nicely, IMO, so that aspect of the idea is worth considering.

Yes, I have incorporated these into the alternatives section of the proposal. I appreciate your suggestions!

I’ll be submitting a PR later today or tomorrow if no significant new feedback arises.

···

On Jun 24, 2016, at 3:06 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Fri, Jun 24, 2016 at 2:50 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 24, 2016, at 10:41 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

extension Array: Literal.ArrayProtocol

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:37:27, Adrian Zubarev (adrian.zubarev@devandartist.com <mailto:adrian.zubarev@devandartist.com>) schrieb:

Really? I must have overlooked that some pitched that design.

Okay now that I think through this whole scenario, I like the underscore iff there is a good name that will be present in the final version.

When Swift 3 drops, I’ll write a proposal for nested protocols which will refine your design (the original author went missing after pitching this idea, and Joe Groff told me that this probably out of scope for Swift 3)!

Your current design might become this in Swift 3.X and all protocols marked with an underscore will disappear:

public /* closed */ enum Syntax {
  public protocol NilLiteral { ... }
  public protocol BooleanLiteral { ... }
  public protocol IntegerLiteral { ... }
  public protocol FloatLiteral { ... }
  public protocol UnicodeScalarLiteral { ... }
  public protocol ExtendedGraphemeClusterLiteral { ... }
  public protocol StringLiteralLiteral { ... }
  public protocol StringInterplolationLiteral { ... }
  public protocol ArrayrLiteral { ... }
  public protocol DictionaryLiteral { ... }
}

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:25:45, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

The design in this proposal comes from the standard library team. The intent is for the use of underscore here to be consistent with other uses of underscore prefix in the standard library. I’m not sure why you think this is different than the rest...

On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I’m aware of that fact, but all types with underscore even in the stdlib telling me to keep my hands of them, because something might happen to them.

As an example we have _Strideable protocol which is visible by its name, but its declaration isn’t visible at all:
// FIXME(ABI)(compiler limitation): Remove `_Strideable`.
// WORKAROUND rdar://25214598 <> - should be:
// protocol Strideable : Comparable {...}

% for Self in ['_Strideable', 'Strideable']:
From Stride.swift.gyb <https://github.com/apple/swift/blob/63c36dff0a327874a5041d46335bde314bc108d8/stdlib/public/core/Stride.swift.gyb&gt;

--
Adrian Zubarev
Sent with Airmail

Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

The underscore is used in the same way it is used elsewhere in the standard library. The protocols must be public because they need to be visible to user code in order for the design to work correctly. However, they are considered implementation details that users really shouldn’t know about. This pattern is well established in the standard library.

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

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

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