Re: [swift-dev] Differences between Xcode official toolchains and tagged releases from repository

[Zhao Xin via swift-dev]

I think if you want to upload your apps to App Store, you will need the
toolchain together with Xcode. Also, playground should only work with that
toolchain.

Zhaoxin

On Mon, Oct 3, 2016 at 6:34 PM, Daniel Martín via swift-dev <
swift-dev@swift.org> wrote:

> Hello, all:
>
> Is there any difference between the official toolchains included with
> Xcode and the tagged releases from the repository? Maybe the Xcode team is
> using some special flags for compilation or applying internal fixes? I ask
> this question because we're seeing some projects that compile fine with the
> official toolchain, but fail to do so with one downloaded from the
> repository, from the exact tagged version.
>
> Before we investigate this further, is it possible to create an "official"
> Swift toolchain using the build scripts (for internal use, I assume we
> cannot upload to the Store with that toolchain)? Does the Xcode team
> generate the binaries from the repository tags?
>
> Thanks,
> Daniel Martín
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Pitch] Remove "Default will never be executed" Warning?

[Zhao Xin via swift-dev]

​It will be better to use `fatalError()` in `default` part that you think
never be needed.​

default:
fatalError("This should never happen!")

Zhaoxin

On Tue, Nov 29, 2016 at 11:25 AM, Dave Abrahams via swift-dev <
swift-dev@swift.org> wrote:

>
> on Sun Nov 27 2016, Slava Pestov  wrote:
>
> >> On Nov 27, 2016, at 4:32 PM, David Sweeris via swift-dev <
> swift-dev@swift.org> wrote:
> >>
> >>>
> >>> On Nov 26, 2016, at 5:25 PM, Robert Widmann via swift-dev <
> swift-dev@swift.org
> > > wrote:
> >>>
> >
> >>> Hello all,
> >>>
> >>> I’ve seen and been a part of a number of conversations recently where
> talk of planning for “resilient enums”, or even just authors that ship
> frameworks that will eventually offer a binary option that export
> enum-based APIs.  The consensus seems to be that the only safe way to deal
> with this situation is to always cover a `switch` statement with a default,
> regardless of whether the totality checker thinks you’ve covered all
> cases.  Currently, the compiler warns when this is the case, as in stdlib
> >>>
> >>> extension ProcessTerminationStatus {
> >>>   var isSwiftTrap: Bool {
> >>> switch self {
> >>> case .exit(_):
> >>>   return false
> >>> case .signal(let signal):
> >>>   return CInt(signal) == SIGILL || CInt(signal) == SIGTRAP
> >>> default:
> >>>   // This default case is needed for standard library builds where
> >>>   // resilience is enabled
> >>>   return false
> >>> }
> >>>   }
> >>> }
> >>>
> >>> I think this warning doesn’t actually serve a purpose and I’d like to
> remove it, or at the very
> > least curb it.  Currently, I see three paths forward:
> >>>
> >>> 1) Do nothing.
> >>> 2) Completely remove the diagnostic
> >>> 3) Only emit the diagnostic when the case-tree is switching over
> enum(s) declared inside the
> > current module.
> >>
> >> Has the “resilient enum” thing been finalized, or is this kind of code
> just a preventative
> > measure?
> >>
> >> Also, if “resilience” is a compiler flag, there's a fourth option:
> Disable the warning on builds
> > that have “resilience” enabled.
> >
> > The warning is already gone (and the default cause is required) when
> > the standard library and overlays are built with resilience
> > enabled. The issue is that resilience is off by default.
> >
> > I agree the warning is annoying; we should figure out something.
>
> There should also be a way to write code that will compile without
> warnings whether or not you have resilience enabled. ;-)
>
> --
> -Dave
>
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev