jakt icon indicating copy to clipboard operation
jakt copied to clipboard

Jakt functions aren't visible from separately compiled C++ files

Open ADKaster opened this issue 3 years ago • 2 comments

if I have a file, utility.jakt that defines a cool array --> string join method, like so:

function join(anon strings: [String], separator: String) throws -> String {
    mut output = ""
    
    mut i = 0uz
    for s in strings.iterator() {
        output += s
        if i < strings.size() - 1 {
            output += separator
        }
        i++
    }

    return output
}

The generated C++ function is always static, so, file local to the translation unit that's ultimately created from utility.jakt.

This poses problems for:

  • C++ interoperability (C++ TUs or shlibs or executables calling jakt code)
  • Splitting each module into its own C++ TU (compile time speed anyone?)

A "simple" solution to this issue would be to introduce a new keyword, export.

Export would have some cute semantics:

  • Visible to other modules
  • Not-static, so visible to other code

Probably would want both a function decorator and a block context, similar to namespaces

export function join(anon strings: [String], separator: String) throws -> String {
    ...
}
export {
 function join(anon strings: [String], separator: String) throws -> String
 function union(anon strings: [String], other_strings: [String]) throws -> String {
}

Should we allow exporting imported items?

Now it's sounding like all the things C++ modules are supposed to do :)

ADKaster avatar Jul 31 '22 06:07 ADKaster

Another alternative would be to introduce a keyword exactly like C++'s static (private? local?) to explicitly mark functions as module-private, and sidestep the extra implications of "export".

Then that leaves the question of what's the best default? Export-all or hide-all?

ADKaster avatar Jul 31 '22 06:07 ADKaster

You could also consider using (supporting?) the anonymous namespace in jakt.

predmond avatar Aug 01 '22 16:08 predmond