> On Jun 3, 2016, at 8:11 PM, John McCall <rjmcc...@apple.com> wrote: > >> On Jun 3, 2016, at 5:13 PM, Matthew Johnson <matt...@anandabits.com> wrote: >> On Jun 3, 2016, at 6:23 PM, John McCall <rjmcc...@apple.com> wrote: >> >>>>> On Jun 3, 2016, at 4:07 PM, David Sweeris <daveswee...@mac.com> wrote: >>>>> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> Using an external parameter label in a declaration and allowing it to be >>>>> omitted at the call site does not feel like the right answer to me. I >>>>> think we can find a better way to present this syntactically. >>>> >>>> +eleventy gajillion >>> >>> I'm actually quite happy with the user-facing aspects of the current >>> literal protocols and see zero reason to update them for this, so if that's >>> the choice, I'll just leave this aside. >> >> Are you suggesting that preserving the current syntax of the literal >> protocols is more important than fixing this behavior so it works like most >> people seem to expect? Why not be open to other syntactic solutions? > > I think fixing the behavior is good, and I stand by this proposal.
I agree fixing it is good and we should do it. I’m just trying to explore the solution space to see if there are any alternatives that might be more appealing. Clearly you’ve thought about this a lot but it’s a new topic to consider for the rest of us. :) > There is, however, nothing glaringly wrong with the literal protocols. They > do not need to redesigned simply because we found a syntactic interaction > that needs to be cleaned up. > > There are good reasons the protocols have evolved the way they have. The > labels clearly mark the purpose of each initializer and distinguish one from > another on types that support multiple literal kinds. The labels also > clearly indicate that the initializers are not intended for general use. The > argument(s) to the initializer do not always represent a single value of > literal type. Some protocols provide multiple initializers, and it is quite > possible that that will become gradually more common as we explore ways to > grant more flexibility to code outside of the standard library. And we > actually consider it good that you can invoke these initializers explicitly; > it's only accidental use that we feel it's important to avoid, which labels > provide excellent protection against. If it is important that these initializers be callable directly I suppose the label is the only way to go. I can’t think of a reason why this is necessary though. I would consider it bad design for a type that expects to be initialized with an Int variable to require its callers to use the label, as opposed to providing an alternate initializer that doesn’t have a label with “literal” in its name. Are there specific use cases where you think this capability is important or is it just the principle that you should be able to call any initializer you write? -Matthew > > If you have specific criticisms of any of the literal protocols, e.g. you > find them limiting or non-performant for your own types, then you are welcome > to raise them here. However, resemblance to actual literal syntax has never > been a design goal for the literal protocols; and besides, this will always > be a secondary literal syntax, one far less important than contextual typing. > > John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
