Welcome, New Testers!

Hi everyone.

we just invited a whole bunch of new people to the Silver beta, so i expect this forum to be getting busy soon ;).

To get started,make sure to check out http://docs.elementscompiler.com/Silver for our core beta docs on Silver.

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.

You can find our Beta FAQ here,and check out the Differences and Limitations and :language Extensions topics to learn how Silver differs from Apple Swift.

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.

That said: HAVE FUN!

yours,
marc

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.

func Button_Click(_ sender: System.Object!, _ e: System.Windows.RoutedEventArgs!) {
if let btn = sender as? Button { btn.Content = curUser }
curUser = curUser == “X” ? “O” : “X”
if curUser == “X” return
Calculate_O_Move()
}

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 (:wink: required to separate two statements on the same line
4 Semicolon (:wink: 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.

Thanx!

the underscore means that the parameter name does not become part of the function name. for example these two methods:

foo(someValue: int; _ someOtherValue: int);
bar(someValue: int; someOtherValue: int);

you would call such as

foo(1,2);
bar(1, someOtherValue: 2);

(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!

Thanks, logged as bugs://71498

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.

The error handling can use some more work, but:

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.

bugs://71498 got closed with status fixed.

1 Like

Ah, I shoulda known better, as I did read that all “if” statements must be braced to avoid the “dangling else” bug! Thanks!

1 Like

Hey, I’m Director Mobile Univision Television. Would love to be invited to the beta, sir.

Michael,

you can join the beta at http://secure.remobjects.com/portal/silver.

yours,
marc

typealias Chessman = [String: (alpha: Character, num: Int)?]
var сhessmans: Chessman = ["Белый король": (alpha: "f", num: 1), "Белый ферзь": (alpha: "e", num: 1), "Чёрная пешка": (nil)]

func updateFigure( inout chessman: Chessman, name: String, position: (Character, Int)? = nil) {
    if position != nil && chessman[name] != nil && chessman[name]! != nil {
        let (alpha, num) = position!
        chessman[name]!!.alpha = alpha
        chessman[name]!!.num = num
    } else {
        chessman[name] = position
    }
}

updateFigure(&сhessmans, name: "Чёрная sdf", position: ("a", 3))
print(сhessmans)

why?

What’s !! and where is it defined?

this
print(сhessmans[“Белый король”]) // Optional(Optional((“f”, 1)))
print(сhessmans[“Белый король”]!) // Optional((“f”, 1))
print(сhessmans[“Белый король”]!!) // (“f”, 1)

here it work http://iswift.org/playground
and https://swiftlang.ng.bluemix.net/#/repl (need set swift 2)

@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.

@hurden: afaik 74969 was fixed in april, 71477 and 71476 in june, if you are on the beta, those all should work for you.

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.

For example:
This thing doesn’t compile for me:

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.