Re: [swift-users] The value of enums

[Dave Abrahams via swift-users]

on Sun Nov 06 2016, Nevin Brackett-Rozinsky 
 wrote:

> …oh, I just realized we’re on -users not -evolution here. Perhaps I’ll
> bring this up next time switch expressions are proposed.

Thanks ;-)

-- 
-Dave
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] The value of enums

[Nevin Brackett-Rozinsky via swift-users]

To the topic at hand, the project I’m currently working on has 2 enums,
both with String raw values. For comparison, it has 3 classes (a Formatter
subclass, the app delegate, and one more), 4 protocols, and 47 structs.

One of the enums exists to select among the handful of struct types which
conform to one of the protocols.



> There are several things we have thought of that could potentially improve
> the situation, most notably exposing each case as an optional property.


That would be very nice.


I'd also really like to see switch-expressions (as opposed to statements).


Hmm, would a syntax like this be appropriate?

switch someValue -> [String] {
case .helloWorld: return ["Hello", "world"]
default: return []
}

That way the existing switch statement could remain as-is, and the familiar
function syntax would be used to specify the return type for switch
expressions. The “return” keyword could even be elided for single-line
cases as well, much like closures.

…oh, I just realized we’re on -users not -evolution here. Perhaps I’ll
bring this up next time switch expressions are proposed.

Nevin


On Sun, Nov 6, 2016 at 4:31 PM, Dave Abrahams via swift-users <
swift-users@swift.org> wrote:

>
> on Sun Nov 06 2016, Tino Heth  wrote:
>
> > Enums are a fundamental part of Swift, so I guess they won't change
> > much — but I wonder if anyone shares my observations in real-life use…
> >
> > Afair, there are three different types of enums:
> > - Enums with raw values
> > - enums with associated objects
> > - Plain enums (no underlying value)
> >
> > I use the first type quite often (as a convenient way to create string
> > constants, or for serialization), but see no real value in plain enums
> > (they offer nothing over enums backed with a raw value).
> >
> > The second type is special:
> > It looks like a really cool concept, and and I started several designs
> > based on them — just to realize later that structs and classes are a
> > better fit.
> > My conclusion so far is that enums perform bad as soon as you want to
> > attach additional data or behavior; one or two computed properties are
> > ok, but those switch-statements quickly become a burden.
> > There are some options to work around this problem, but I guess I'll
> > just stay away from enums with associated objects by default (with the
> > exception of error-types — imho those can be modeled quite nicely).
> >
> > So, that's my current perception, and I'm curious if others had
> > similar experiences — or, even more interesting, completely different
> > observations and elegant solutions based on enums.
>
> I have personally always found that exuberant use of that kind of enum
> results in ergonomics and readability difficulties.  There are several
> things we have thought of that could potentially improve the situation,
> most notably exposing each case as an optional property.  I'd also
> really like to see switch-expressions (as opposed to statements).  I'm
> not sure if that's really all we need in order to allow enums to reach
> their potential, though.
>
> --
> -Dave
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 3 Android hangs & crashes

[Eric Wing via swift-users]

On 10/31/16, Eric Wing  wrote:
> Hello, I've been trying to get Swift 3 working on Android. (I
> previously had Swift 2.x working.)
>
> I have the baseline components built following the standard
> Android/Swift instructions.
>
> But when I go to make a trivial, but real Android
> app (i.e. start in Java Activity and use JNI/LoadLibrary to get to
> Swift), the Swift code seems to hang (freeze?) whenever my Swift code
> calls print("foo").
>
> Removing all print calls, allows my trivial code to run correctly. But in
> slightly more complicated test programs (which call into other C
> libraries), I'm getting program crashes. It looks like libc triggers
> some kind of abort call in these cases. I know these C libraries work
> in non-Swift cases.
>
> My best guess right now is since Swift print() is also broken, I think
> there might be some problem related to libc++ (and maybe its
> interaction with libc) which is used in the build process. (The
> Android NDK docs warn about std::cout buffering breaking if you have
> multiple static linked libc++, but I'm not statically linking it.)
>
> I'm currently using libc++_shared.
> I updated my repo a few days ago which includes a fix for NDK r13
> which I am using.
>
>
> Does this problem ring a bell for anybody?
> Or can somebody help me figure out how to start debugging this? I've
> been trying a lot of different things behind the scenes, but I'm
> starting to run out of ideas.
>
> Thanks,
> Eric
>

I discovered there is a serious deadlock bug in Android 5.0. flockfile
on stdout/stderr causes a deadlock. Swift print() ultimately calls
flockfile, which in turn causes a deadlock. I verified this by first
commenting out the lock functions in the print function, and then
later by commenting out the flockfile/funlockfile implementations in
the Stubs.cpp.


One of the comments here mentions this bug:
https://chengyihe.wordpress.com/2015/10/31/android-child-process-hits-mutex-deadlock-in-printf-after-fork/

The workaround seems to be either to remove the call to flockfile() or
update to Android 5.1. I upgraded my device to 5.1 and the problem
disappeared.

But thanks to Android fragmentation, going to 5.1 this means we lose
another 13.1% of devices, leaving us only 40.6% of devices.


This does bring up another issue though, at least for print() and
anything stdout/stderr related on Android. On Android, sending
anything to stdout/stderr via the NDK is effectively useless because
they are effectively sent to /dev/null. (The ‘adb shell setprop
log.redirect-stdio true’ trick doesn’t work for the NDK. There is one
convoluted trick to redirect using pipes in your codebase, but that is
a different can of worms.)

In general, print() statements need to go through
__android_log_write() and __android_log_print() on Android for anybody
to see anything. Is this something we should implement in Swift?

Thanks,
Eric
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] The value of enums

[Dave Abrahams via swift-users]

on Sun Nov 06 2016, Tino Heth  wrote:

> Enums are a fundamental part of Swift, so I guess they won't change
> much — but I wonder if anyone shares my observations in real-life use…
>
> Afair, there are three different types of enums:
> - Enums with raw values
> - enums with associated objects
> - Plain enums (no underlying value)
>
> I use the first type quite often (as a convenient way to create string
> constants, or for serialization), but see no real value in plain enums
> (they offer nothing over enums backed with a raw value).
>
> The second type is special:
> It looks like a really cool concept, and and I started several designs
> based on them — just to realize later that structs and classes are a
> better fit.
> My conclusion so far is that enums perform bad as soon as you want to
> attach additional data or behavior; one or two computed properties are
> ok, but those switch-statements quickly become a burden.
> There are some options to work around this problem, but I guess I'll
> just stay away from enums with associated objects by default (with the
> exception of error-types — imho those can be modeled quite nicely).
>
> So, that's my current perception, and I'm curious if others had
> similar experiences — or, even more interesting, completely different
> observations and elegant solutions based on enums.

I have personally always found that exuberant use of that kind of enum
results in ergonomics and readability difficulties.  There are several
things we have thought of that could potentially improve the situation,
most notably exposing each case as an optional property.  I'd also
really like to see switch-expressions (as opposed to statements).  I'm
not sure if that's really all we need in order to allow enums to reach
their potential, though.

-- 
-Dave

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] The value of enums

[Erica Sadun via swift-users]

> On Nov 6, 2016, at 4:07 AM, Tino Heth via swift-users  
> wrote:
> 
> Enums are a fundamental part of Swift, so I guess they won't change much — 
> but I wonder if anyone shares my observations in real-life use…
> 
> Afair, there are three different types of enums:
> - Enums with raw values
> - enums with associated objects
> - Plain enums (no underlying value)
> 
> I use the first type quite often (as a convenient way to create string 
> constants, or for serialization), but see no real value in plain enums (they 
> offer nothing over enums backed with a raw value).
> 
> The second type is special:
> It looks like a really cool concept, and and I started several designs based 
> on them — just to realize later that structs and classes are a better fit.
> My conclusion so far is that enums perform bad as soon as you want to attach 
> additional data or behavior; one or two computed properties are ok, but those 
> switch-statements quickly become a burden.
> There are some options to work around this problem, but I guess I'll just 
> stay away from enums with associated objects by default (with the exception 
> of error-types — imho those can be modeled quite nicely).
> 
> So, that's my current perception, and I'm curious if others had similar 
> experiences — or, even more interesting, completely different observations 
> and elegant solutions based on enums.


Enums:

* Great for umbrella type implementation
* Plain enums: perfect for enumeratable states and defining roles.
* Associated types: I use them mostly for Result type, but also handy for 
things like 
  JSON parsers,  which are Swift's mandated follow-on to "Hello World"
* Enums with raw values: I mostly stick to stringity ones, where there's a 
state or role but
  I want to have easy access to the name as well as the role, and integer ones, 
where I can
  repurpose the number elsewhere
* I really love using enums with switch statements, and compiler guarantees of 
case 
   completeness.

I'd put forth that enum cases should be few, simple, and focused. They should 
not be 
used as flags.  When used well, they should feel obvious and integrate well 
into 
switch statements. 

-- E

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] The value of enums

[Tino Heth via swift-users]

Enums are a fundamental part of Swift, so I guess they won't change much — but 
I wonder if anyone shares my observations in real-life use…

Afair, there are three different types of enums:
- Enums with raw values
- enums with associated objects
- Plain enums (no underlying value)

I use the first type quite often (as a convenient way to create string 
constants, or for serialization), but see no real value in plain enums (they 
offer nothing over enums backed with a raw value).

The second type is special:
It looks like a really cool concept, and and I started several designs based on 
them — just to realize later that structs and classes are a better fit.
My conclusion so far is that enums perform bad as soon as you want to attach 
additional data or behavior; one or two computed properties are ok, but those 
switch-statements quickly become a burden.
There are some options to work around this problem, but I guess I'll just stay 
away from enums with associated objects by default (with the exception of 
error-types — imho those can be modeled quite nicely).

So, that's my current perception, and I'm curious if others had similar 
experiences — or, even more interesting, completely different observations and 
elegant solutions based on enums.

- Tino
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users