Skip to content

Replace function with func#232

Merged
alexcrichton merged 3 commits intobytecodealliance:mainfrom
esoterra:function-func
Jun 9, 2022
Merged

Replace function with func#232
alexcrichton merged 3 commits intobytecodealliance:mainfrom
esoterra:function-func

Conversation

@esoterra
Copy link
Contributor

@esoterra esoterra commented Jun 6, 2022

This implements #163 changing the function WIT keyword to be func.

@alexcrichton
Copy link
Member

Thanks for this! I'll note though that I tagged #163 with syntax because I think we need to probably confirm we want to deviate from core wasm's and the component model's precedence of "func" with "function" but I don't think it's otherwise necessarily a clear-cut decision that we should migrate to "func". I think it would be good to get some feedback from other *.wit stakeholders and see what their thoughts are on a change like this as well.

@esoterra
Copy link
Contributor Author

esoterra commented Jun 7, 2022

We'd love to start having those conversations. We're not dead-set on implementing this change, we just want to settle this question sooner than later because switching will only get harder.

(created a Zulip thread here to collect feedback)

@peterhuene
Copy link
Member

While I personally prefer func based on the reasoning that it corresponds to the underlying WebAssembly proposal (also less typing...), I don't have a strong opinion on the particular token we use; however, I strongly agree that this needs to be decided upon by the stakeholders (open question: how do we identify the stakeholders?) sooner than later to avoid having a larger wit corpus in the wild to update.

@lukewagner
Copy link

lukewagner commented Jun 8, 2022

Coincidentally, I was just having a chat with a number of distinct wit-bindgen users and, taking a quick poll of the room, essentially everyone said they preferred func to function (but were "fine" with function and hence hadn't cared enough to raise the issue). Personally, I think the argument that function is the only token that doesn't line up directly with the component model is pretty compelling.

@esoterra
Copy link
Contributor Author

esoterra commented Jun 8, 2022

On a related note, the other thing that stands out is float32/float64 which is consistent between wit-bindgen and the component model, but both disagree with the WebAssembly spec which uses f32/f64. What was the rationale for that split?

@peterhuene
Copy link
Member

peterhuene commented Jun 9, 2022

@Kylebrown9 See Luke's prior comment (and the discussion that ensued) as to why there's a discrepancy between f32/f64 and float32/float64.

@alexcrichton
Copy link
Member

Ok sounds like there's no major objections to this, and personally I find the symmetry between core wasm and the component model with the *.wit syntax pretty compelling. For that I'm going to merge, thanks @Kylebrown9 for doing this refactor!

@alexcrichton alexcrichton merged commit 7f66bd7 into bytecodealliance:main Jun 9, 2022
@alexcrichton alexcrichton mentioned this pull request Jun 9, 2022
@esoterra esoterra deleted the function-func branch June 9, 2022 19:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants