From 1bc19d8b1c18be2d0972fd8ac62b818a583864d4 Mon Sep 17 00:00:00 2001 From: Alessandro Coglio Date: Mon, 16 Aug 2021 10:22:04 -0700 Subject: [PATCH] [RFC] Extend the native functions RFC a bit more. Explicate how the initially proposed design is consistent with Java, and how the native implementations live in separate files in that design. This better paves the way to the more recent variant of this proposal, currently discussed under alternatives but that may be eventually "swapped" if that's also the rest of the team's consensus. --- docs/rfc/010-native-functions.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/rfc/010-native-functions.md b/docs/rfc/010-native-functions.md index 4d26baf0cc..17b28d6440 100644 --- a/docs/rfc/010-native-functions.md +++ b/docs/rfc/010-native-functions.md @@ -166,6 +166,10 @@ The compiler must know a mapping from native functions in the standard/core libr to the R1CS gadgets that implement them, so it should be just a matter of selecting the appropriate one. Some of this logic must be already present, in order to detect and select the BLAkE2s gadget. +This approach is used in Java, where Java files may declare certain methods as `native`, +without a body but with a declaration of input and output types. +The actual native implementations, i.e. the native method bodies live in different files, as they are written in C. + # Drawbacks This does not seem to bring any drawbacks.