Also check out the new tutorials for creating try first app, here (for Fire) and here for Visual Studio. I’ll be adding more tutorials for additional target platforms very soon.
Finally, remember that we’re still in an early beta phase. the core compiler is getting pretty solid, but i do expect you’ll still find plenty of issues for us. Don’t be shy to report them her in the forum,and don’t be shy to ask questions, and let us know what you think (good or bad). Also, check out the Fire Beta Forums, as well.
HI. Just started with Silver yesterday. I’m impressed by what you’ve done so far. Thought I’d create a simple tic-tac-toe WPF app. Finding that ternary operator and casting are creating compile errors.
Not sure what the underscore means before the param names. Does it mean they’re not supposed to be used, like the underscore in a for loop?
Here are the compile errors I’m seeing. Most are for the ternary line.
1 as! or as? expected, got as
2 closing parenthesis expected, got string
3 Semicolon ( required to separate two statements on the same line
4 Semicolon ( required to separate two statements on the same line
5 closing bracket expected, got colon
6 (E1) opening bracket expected, got “return”
7 (E1) closing bracket expected, got
I apologize if this isn’t the correct place to post this. I didn’t see where to create a new thread.
(on the first parameter, the _ is implied/default, but for auto-generate code such as this,we emit it anyways, for clarity. Instead of you can use # to force a parameter to become part of the name, such as
foobar(# someValue: int; someOtherValue: int);
which you would call such as
foobar(someValue:1, someOtherValue: 2);
As for the compile errors, that does indeed look like a bug. I’ll log that for investigation. Thanx!
Thank you for your clarification! I felt guilty that not more than an hour after I wrote the comment I read the part in my Deitel book on Swift that explained parameter naming involving external/internal names and such.
I should mention that I tried various ways of parenthesizing the ternary expression, but no joy in any configuration.
I saw an example of casting an Int that was something like Int(val_to_be_cast). I don’t know if that would work for reference types.
func Button_Click(_ sender: System.Object!, _ e: System.Windows.RoutedEventArgs!) {
// 1
if let btn = sender as? Button { btn.Content = curUser } /
// 2
curUser = curUser == "X" ? "O" : "X"
// 3
if curUser == "X" return
// 4
Calculate_O_Move()
}
I’m presuming you got the 1 as! or as? expected, got as on // 1, which is as designed, latest swift requires as? or as!, but it looks like you fixed that already.
//2 seems file, but //3 needs a { } around the return:
if curUser == "X" { return }
you are right about the cast though. as? and as! can be used for classes, but Int(15) is a constructor call, which happens to cast the input as it’s constructor body.
I’ll look into improving the error handling for a missing { } of course.
@mh: That being said that means 8.4 official release is not so far away?
And will 8.4 have the protocol compiler limitation fixes that includes ability to extend the base types, 74969, 71477, 71476…, and so on? Since only once there are no these protocol related issues, SwiftBaseLibrary can be made to be a close replicate to apple’s one.
That’s great! What about making base types protocols to work?
Like:
public extension Int32: Equatable {}
public func ==(lhs: Int32, rhs: Int32) -> Bool {
return lhs == rhs
}
I wasn’t able to make something like compile in any way…
This will produce:
/Source/Integer_Extensions.swift(95,8): warning N2: Matching method "static operator Equatable!.==(_ lhs: Equatable!, _ rhs: Equatable!) -> Bool" is missing
/Source/Integer_Protocols.swift(5,17): warning N3: Original type "Equatable" was declared here
/Source/Integer_Extensions.swift(95,8): error E265: Static duck typing failed because of missing methods
I would be very nice to have this, since I would be then able to leverage generics on base types…
Because this thing indeed works:
public class Someclass {
var foo: Int = 0
}
public extension Someclass: Equatable {
public func ==(lhs: Self, rhs: Self) -> Bool {
return lhs.foo == rhs.foo
}
}
That’s not supported yet. Also according to the ever changing swift specifications, that won’t work at all if == is defined outside of the type/extension in swift 3
yeah true, but even you define it inside, same thing.
@ck: So will this be supported in 8.4 public release?
This will be a really big thing for me, especially if the generic constraints and associatedtypes will work fine, that will allow doing stuff protocol-based in a nice way.
I’m not going to promise anything about “Self” related issues for 8.4, we’re going to try but can’t say if it will make it.[quote=“hurden, post:19, topic:5496”]
For example:This thing doesn’t compile for me:
[/quote]
But that’s a completely different thing again ? I can look at that if you give me more information, preferably in a separate post.
required to separate two statements on the same line
