Swift compatibility: Allow selector in @objc attribute

Thanks for supporting the @objc and @nonobjc attributes (and presumably ignoring them?)
There is one issue with it: the @objc attribute can optionally take a name - of a class or an objective c selector. If there are parameters on a method, this includes at least one, but maybe more, colons, which XCode/Clang enforces with an error if you omit them.

In Fire/Silver, if you try using a selector with a colon, Silver cannot parse it:

class MyClass2
{
	@objc(myRenamedMethod:)
	func myMethod(str: String)
	{
	}
	
}

Gives:
/Users/jon/Documents/silvertest15/Program.swift(12,26): error E374: closing parenthesis or comma expected, got colon
/Users/jon/Documents/silvertest15/Program.swift(12,26): error E5: Attributes are not allowed here
/Users/jon/Documents/silvertest15/Program.swift(12,26): error E1: closing bracket expected, got colon

Hopefully fixable with a tweak to your parser grammar?

Thanks, logged as bugs://75450

Bug. @objc already allows you to specify external names, but it just doesn’t handle the colon syntax properly.

Thanks. Is it actually used by the compiler?

it is yes.

so are you saying it will effect the name of a class/method emitted to byte code for example?
Didn’t expect that.
Does it work on property getter/setters for swift properties? So that you could specifiy getBlah for a property called .blah , eg as a workaround for the annoyingly non-standard casing of property accessors:

the objc attribute doesn’t at all influence java, or .net. It’s meant for interop with objc and overrides the internal name it uses there. On java that’s not needed.

As for Java, that’s tricky. If we uppercase it the compiler loses the information needed to get back the original name, and it would conflict if you had a private json vs public Json property.

ok cool, got it now, it slipped my mind that you generate code for iOS as well.

On java properties - could you make it a compiler option to always uppercase the property name when creating the methods, then its the user’s choice, and their fault if they make conflicting names?

It just feels wrong either way at the moment - either the java property names are non standard and feel awkward when using them from java, or using uppercase properties in swift is against the swift coding standards.

bugs://75450 got closed with status fixed.

bugs://i63424 was closed as fixed.

Logged as bugs://i63424.