> On 21 Nov 2016, at 11:52, Jeremy Pereira
> wrote:
>
>
>> On 21 Nov 2016, at 08:42, Rien via swift-evolution
>> wrote:
>>
>> Sure you can do that, but I rather write:
>>
>> struct A.B {…}
>>
>> than
>>
>> extension A { struct B {…} }
>>
>> The first seems much “swiftier” to me.
>
> Hm
> On 21 Nov 2016, at 08:42, Rien via swift-evolution
> wrote:
>
> Sure you can do that, but I rather write:
>
> struct A.B {…}
>
> than
>
> extension A { struct B {…} }
>
> The first seems much “swiftier” to me.
Hmm, objectively, it’s not “swiftier” is it, because Swift has had the
extens
Sure you can do that, but I rather write:
struct A.B {…}
than
extension A { struct B {…} }
The first seems much “swiftier” to me.
In fact, now that this “obvious” dot-notation has been pointed out, I wonder
why this was not the initial implementation instead of the “extension” keyword.
Was the
> On Nov 20, 2016, at 3:22 PM, Tino Heth <2...@gmx.de> wrote:
>
>> Oops, I could've sworn that I did change the subject!
> Feel free to join camp "isn't there something better than mailing lists?" ;-)
Hahaha, that’s exactly what I was thinking when I originally subscribed to the
mailing list sev
The forum can’t appear soon enough. :D
--
Adrian Zubarev
Sent with Airmail
Am 20. November 2016 um 22:23:03, Tino Heth via swift-evolution
(swift-evolution@swift.org) schrieb:
Oops, I could've sworn that I did change the subject!
Feel free to join camp "isn't there something better than mai
> Oops, I could've sworn that I did change the subject!
Feel free to join camp "isn't there something better than mailing lists?" ;-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
ame] + Topic name
>
> As for the current thread:
>
> Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types
>
> Best regards,
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 20. November 2016 um 20:25:50, Zach Wolfe
Forwarding your message to the right thread.
Please use this subject pattern when replying to something:
Re: + [swift-listname] + Topic name
As for the current thread:
Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types
Best regards,
--
Adrian Zubarev
Real type nesting vs. extension nesting creates a new visibility boundary. If
your type somehow depends on the visibility of your parent type scope, it could
became problematic. Just speaking generally here.
Bikeshedding:
struct A {
struct B {}
}
extension A {
struct C {}
}
// Could b
No problem Alexander!
On Sun, Nov 20, 2016 at 1:15 PM Alexander Doloz
wrote:
> Frankly speaking I didn’t know it’s possible with extensions :) Thank you
> for answer, it will be helpful for my project.
> Since this method works my proposal no longer makes much sense.
>
> 20 нояб. 2016 г., в 21:0
Frankly speaking I didn’t know it’s possible with extensions :) Thank you for
answer, it will be helpful for my project.
Since this method works my proposal no longer makes much sense.
> 20 нояб. 2016 г., в 21:05, Derrick Ho написал(а):
>
> struct A {
>var a = 0
> }
>
> extension A {
>s
Alexander, I took your code and "flattened" it with what currently exists
in Swift 3. Is this not flat enough for you?
struct A {
var a = 0
}
extension A {
struct B {
var b = "Bee"
}
}
extension A.B {
struct C {
var c = 0
func someFunc() {
print("something")
}
About scope visibility rules – I think, for now this new syntax should behave
exactly like the old. What’s possible with old syntax should be possible with
the new and vice versa.
To Robert Widmann’s question about real situation where such syntax will be
useful – right now I have a project wher
Imo, it does not need extreme nested code to be useful. I find that more than 1
level of nesting tends to create obfuscation. Probably because we loose the
ability to associate type C with type A. By allowing "struct A.B.C" it is very
clear that C does indeed depend on A.
However, I can already
I always wanted something like this. Can't we extend the idea a little further
and make it `flat extension` instead?
struct A {}
func A.foo() {}
struct A.B {}
It would be some sugar for `extension A { ... }`
--
Adrian Zubarev
Sent with Airmail
Am 20. November 2016 um 04:18:32, Ro
I think this is an interesting proposal, but I don't write enough
extremely-nested code to know that it will do much more than save you some
whitespace - as you say. What situation have you run into specifically where
this kind of code is both called-for and headache-inducing?
~Robert Widmann
Hello, Swift community!
Right now, when we declare nested types in Swift, we have to literally nest
them:
// Swift 3
struct A {
var a = 0
struct B {
var b = 0
struct C {
var c = 0
func someFunc() {
17 matches
Mail list logo
