Jakt functions aren't visible from separately compiled C++ files
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 :)
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?
You could also consider using (supporting?) the anonymous namespace in jakt.