[swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

[Xiaodi Wu]

-1 from me as well. As mentioned before, submodules will require their own
extensive discussion and is another matter entirely from grouping access
modifiers. These two topics don't really share anything in common other
than that they are units of code. I have a hard time subscribing to the
idea that an issue as broad as submodules should be solved with a syntax
that simply means "this is an arbitrary unit of code".

On Wed, Jun 29, 2016 at 1:16 PM, Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> I can’t resist I’ve got a third argument for your ‘scrolling’: Grab a huge
> protocol that does not fit on your screen, which assistance do you have to
> get its access modifier?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 29. Juni 2016 um 20:03:31, Adrian Zubarev (
> adrian.zubarev at devandartist.com) schrieb:
>
> Looking at how c++ has a similar access modifier indent mechanism I’m
> still wondering if you’d argue about scrolling there.
>
> with no assistance to find where it is
>
> An assistant isn’t something the language solves for you. This is a
> different talk about the IDE. Grab some stdlib or foundation code and look
> at the filename and the code inside the file. The file might not contain
> only a single type equal to the filename. Also if there is another huge
> type present and you have a small display and currently looking at some
> specific member in the middle of that that type, which assistance have to
> find out the type of that member? Here we go again: you’re own assistant
> will your own negative argument ‘scrolling’.
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
>
> _______________________________________________
> 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/20160629/5e1c166f/attachment.html>