Use Go standard-library values
This recipe stays on the direct Go boundary. It uses an imported bytes.Buffer value, calls its pointer-receiver methods through addressable local storage, keeps both results from Go APIs visible, and passes a typed arrow back into Go.
Project tree
text
go-standard-library/
└── main.kmSource
ts
import go bytes from "bytes";
import go fmt from "fmt";
import go sort from "sort";
import go strconv from "strconv";
import go strings from "strings";
function main(): void {
let buffer: bytes.Buffer = bytes.Buffer {};
const [written, writeErr] = buffer.WriteString(strings.ToUpper("hello"));
const [parsedNumber, parseErr] = strconv.Atoi("42");
const values = [3, 1, 2];
sort.Slice(values, (left: int, right: int): boolean => values[left] < values[right]);
fmt.Println(
written,
writeErr === nil,
buffer.String(),
parsedNumber,
parseErr === nil,
values,
);
}Run
sh
keika check main.km
keika run main.kmExpected output:
text
5 true HELLO 42 true [1 2 3]Read the boundary
bytes.Bufferkeeps the identity and method set of the real Go type.bufferis a named, addressable value. The compiler can therefore callWriteStringandString, whose Go method set includes pointer-receiver behavior.- The nested
strings.ToUppercall finishes beforeWriteStringstarts; each target and argument evaluates once in source order. WriteStringandstrconv.Atoiexpose their Go results directly.[written, writeErr]and[parsedNumber, parseErr]are compiler-known result lists, not tuple objects.- Raw Go
errorvalues compare withnil. Nothing converts them to exceptions or hides them behind a result wrapper. sort.Slicereceives a Kinmokusei arrow with the exact Go callback shape. The arrow capturesvalueslexically and Go calls it during sorting.
Use Result<T> and postfix ? when propagation is part of your own function contract. Keep explicit results when the current scope must inspect, combine, or report them separately.
Continue with the Go interoperability guide, the interop support matrix, or Result parsing.