[swift-evolution] Revisiting SE-0110

Xiaodi Wu xiaodi.wu at gmail.com
Thu Jun 15 11:05:58 CDT 2017


On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution <
swift-evolution at swift.org> wrote:

> > One (tangential) thing that came up is that tuple element names in tuple
> *patterns* should probably be deprecated and removed at some point.
> Without looking, what variables does this declare?:
> >
> >   let (a : Int, b : Float) = foo()
>
>
> I think it would be better if the compiler raised a warning whenever you
> tried to redefine a builtin type.


That’s essentially my preferred solution as well, as it gets to the root of
the confusion.

Naming a variable the same as a type should be similar to naming a variable
the same as a reserved keyword and require backticks. (A previous
suggestion to enforce capitalization falls down with full Unicode support
and complicates interop where imported C structures might be lowercase and
constants might be all caps.) No need to treat built-in types specially;
it’s equally a problem with types imported from other libraries, which can
be shadowed freely today. For full source compatibility this can be a
warning instead of an error–should be sufficient as long as it’s brought to
the user’s attention. In fact, probably most appropriate as a warning,
since the _compiler_ knows exactly what’s going on, it’s the human that
might be confused.

`let (a : Int, b : Float) = foo()` is confusing but if you were to use your
> own type (e.g., `struct S {}` and replace Int and Float with S) you would
> get a compiler error. If the compiler warned you that you were reassigning
> Int and Float, you’d probably avoid that problem. Or, for a more extreme
> fix, we could make reassigning builtin types illegal since there is pretty
> much no valid reason to do that.
>
>
> > On Jun 15, 2017, at 8:10 AM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Jun 14, 2017, at 11:01 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >>
> >>> On Jun 12, 2017, at 10:07 PM, Paul Cantrell <cantrell at pobox.com>
> wrote:
> >>>
> >>> What’s the status of this Chris’s double parens idea below? It
> garnered some positive responses, but the discussion seems to have fizzled
> out. Is there something needed to help nudge this along?
> >>>
> >>> What’s the likelihood of getting this fixed before Swift 4 goes live,
> and the great wave of readability regressions hits?
> >>
> >> We discussed this in the core team meeting today.  Consensus seems to
> be that a change needs to be made to regain syntactic convenience here.
> Discussion was leaning towards allowing (at least) the parenthesized form,
> but more discussion is needed.
> >>
> >>
> >> One (tangential) thing that came up is that tuple element names in
> tuple *patterns* should probably be deprecated and removed at some point.
> Without looking, what variables does this declare?:
> >>
> >>   let (a : Int, b : Float) = foo()
> >
> > Another option would be to require let to appear next to each name
> binding instead of allowing a single let for the whole pattern.  I
> personally find that much more clear despite it being a little bit more
> verbose.
> >
> >>
> >> ?
> >>
> >> -Chris
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170615/e9a5875d/attachment.html>


More information about the swift-evolution mailing list