Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Happy 2016!
> 
> I am working on an initial proposal for adding support for C language targets 
> to the Swift package manager, and am interested in feedback:

The idea of including C libraries/code in Swift projects *without* having to 
use Xcode strikes me as *very* valuable. Two questions:

a) for item (2) in "solution" I see the advantages of placing the bridging in a 
separate directory, but I want to point out that this may make the interactions 
between various devenvs and things like GitHub more annoying. Xcode's 
Bridging-Header solution has it's own problems, but may be easier to work with 
in complex projects. Generally I think more flexibility here might be valuable, 
even going so far as a ".bh" for the bridging files, allowing them to be placed 
anywhere.

b) for (3), I'm facing this problem right now porting some very old C that has 
a main.c that includes main() as well as other more general code that the rest 
of the system uses. I solved this by changing main(), but that's not ideal, I 
would greatly prefer to use the original code verbatim. So for the 10% of cases 
where this is a problem, perhaps a compiler directive would be useful?


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

Re: [swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 9:38 AM, Nicky Gerritsen  wrote:
> 
> Defer is used to make code *always* run, even if the function terminates 
> early. Imagine:

Which is precisely why I called it 'always'. So in your example:

func doSomethingWith(x: Int) {
print(“1”)
defer { print(“2") }
if x > 3 { defer { print(“yay”); return }
print(“3”)
}

I would say:

func doSomethingWith(x: Int) {
print(“1”)
print(“3”)
always {
print(“2")
if x > 3 { print(“yay”) }
}
}

This is functionally identical, but both the syntax and program flow are 
greatly improved.

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

Re: [swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 12:56 PM, Tim Hawkins  wrote:
> 
> Again my 2 cents
> 
> Other languages use "deffer", and have very simular semantics

No, they don't. With the exception of "Go", I'm unfamiliar with any other 
language that implements this feature *in this fashion*.

> there is no benifit gained from being different, and it makes peoples task of 
> transfering from other systems easier.

Precisely why I make this suggestion. Swift is the oddball here, using 
something that is decidedly non-standard as well as confusing. Why not use a 
solution that is widely used and better?

> What is there works just fine and achives the result it was designed to do. 
> Why do we need to change it?

The same could be said for Obj-C, yet here we are.

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

Re: [swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 1:26 PM, Javier Soto  wrote:
> 
> How would always behave if the function has an early return?

Exactly the same way as 'defer' would behave if the function has an early 
return.

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