added code to remove default arguments from overridden function definition

[torlangballe]

No description provided.

[angelolloqui]

Approved and changed with some additional changes (see comments)

[angelolloqui]

great! this is the kind of tests useful. I am going to add a second method with default arguments not overriden to check they are not removed in that case

[angelolloqui]

Very minor, but it is good practice to try to keep formatting as close as possibe to the standard accepted Swift. In this case, the space between x and Int. Not a reason to reject the PR, but just a comment (I changed it myself)

[torlangballe]

Ah, yes. I started using swift without spaces between label and type in arguments, but switched a while back, but still forget sometimes...

[angelolloqui]

I am moving this function to a private method inside the main class. There is no real benefit of it since we are not inheriting for now, but just for consistency with the rest.

[angelolloqui]

Instead of checking the modifiers directly, I am going to move it to an extension like the isStatic because it is a handy check to be used by others in future (and safer to check the type directly rather than the text value)

[angelolloqui]

Merged and created Issue with the sample code for better tracking (#90)

[torlangballe]

Great. I'll delete my branch and start a new pull request on a new branch, does that sounds right?

PS: Next down the file was a call to something that tranformed function definitions to make operator functions in kotlin by prefixing them with operator_: in swift.
Not sure this is general enough for your repo, or if some kind of hook to transform function-definitions chould be added instead?

class func TransformKotlinFunctionDeclarations(_ tokens:[Token]) -> [Token] {
    // https://kotlinlang.org/docs/reference/operator-overloading.html
    var newTokens = tokens.filter { $0.kind != .keyword || $0.value != "mutating" }
    if let i = findToken(kind:.keyword, val:"fun", tokens:newTokens) {
        let j = i + 2
        let t = newTokens[j]
        if t.kind == .identifier {
            var name = ""
            // this allowes special operator_ prefixed functions to become operators in kotlin
            if stringHasPrefix(t.value, prefix:"operator_", rest:&name) {
                newTokens[j] = changedValueToken(t, name)
                if let origin = t.origin, let node = t.node {
                    newTokens.insert(origin.newToken(.space, " ", node), at:i)
                    let op = origin.newToken(.keyword, "operator", node)
                    newTokens.insert(op, at:i)

                }
            }
        }
    }
    return newTokens
}

[angelolloqui]

Great. I'll delete my branch and start a new pull request on a new branch, does that sounds right?

Yes, that should be the way to go, each feature in a new branch, always starting from the most recent commit on develop. That way we can merge them in isolation and keep conversations short.

[angelolloqui]

Regarding your operation question, do you have a concrete example? (Swift version and what is expected/obtained in Kotlin)

[torlangballe]

Hi Yes, I have a ZRect struct with these functions: func operator_plus(_ a:ZRect) -> ZRect { return ZRect(min:pos + a.pos, max:Max + a.Max) } swift-only (not translated): func +(me:ZRect, a:ZRect) -> ZRect { return me.operator_plus(a) } and in kotlin my setup translates to: operator fun plus(a: ZRect) : ZRect = ZRect(min = pos + a.pos, max = Max + a.Max) it’s not ideal, but good to ensure code code is the same in swift and kotlin. tor

[angelolloqui]

I am not sure I understand why you have that operator_plus function. If you have this swift code:

func +(me:ZRect, a:ZRect) -> ZRect { return ZRect(min: me.pos + a.pos, max: me.max + a.Max) }

then this could be translated to Kotlin like:

operator fun plus(a: ZRect) : ZRect = ZRect(min = pos + a.pos, max = max + a.max)

and in both cases it could be used normally as:
rectA + rectB

Why do you need the artificial operator_plus? is it because one is a function and the other a method?

[angelolloqui]

BTW, there is a related issue #43, maybe we should move the conversation there