Skip to content
This repository has been archived by the owner on Aug 17, 2022. It is now read-only.

How possible is it to have two string types? #138

Closed
trusktr opened this issue Aug 5, 2021 · 14 comments
Closed

How possible is it to have two string types? #138

trusktr opened this issue Aug 5, 2021 · 14 comments

Comments

@trusktr
Copy link

trusktr commented Aug 5, 2021

It seems after the last vote that string will be a usv string. Is adding a second type, say wtfstring (because "domstring" is DOM-specific, and the terminology may have nothing to do with other languages like C# or Java), something that is feasible?

@RossTate you mentioned the domstring idea here along with intra-trust performance which sounds nice: #135 (comment)

Would that require an addon proposal to Interface Types? Or would it be it's own separate proposal? Or a combination of the two?

@RossTate
Copy link

RossTate commented Aug 5, 2021

If the questions are directed at me, what I was describing would probably work best as a separate proposal at (or closer to) the wasm layer rather than the component layer. Each Interface Type would/could then essentially be implementable as a library in that proposal whose API is standardized and adopted into the component layer. Thus the last vote was basically that the component model should adopt a standard library whose API provides a type string along with specialized exports for lifting/lowering utf-8 and utf-16 strings as well as more general (implicit) coercions to/from the list char type.

As for domstring, one could develop an API/library for it using the lower proposal, and then that could be either used conventionally within some smaller ecosystem, or officially incorporated into the JS API for more efficient JS-wasm exchanges, or incorporated into the component model more broadly. So my expectation is that it would be more of a staged process - you can get immediate access to the tech to use between your own systems, but you'd need broader community approval to use the tech between your systems and other people's systems (and you can use your own implementation using the lower-level proposal to illustrate its utility).

@lukewagner
Copy link
Member

Agreed that the right place to discuss proposals for other kinds of strings would be in a separate proposal than Interface Types.

@lukewagner
Copy link
Member

Closing this issue since I think the question is answered.

@trusktr
Copy link
Author

trusktr commented Aug 28, 2021

@lukewagner I was asking about having two string types inside of interface types. Do you imagine a separate proposal can add a new string type to interface types? (It seems that's a lot of friction for something that can just happen here).

@fgmccabe
Copy link
Contributor

fgmccabe commented Aug 28, 2021 via email

@conrad-watt
Copy link

conrad-watt commented Aug 28, 2021

I'd add that our consensus in the previous CG meeting was not only that string should be list-of-USV, but also that no other type of string should be added to IT. So any vote to add an additional string type would be a vote to overturn our previous consensus. As was noted in the meeting, new experimental evidence (e.g. of widespread bugs) would likely be required for us to revisit this decision. I personally would not support any vote that merely attempts to relitigate the previous debate.

@dcodeIO
Copy link

dcodeIO commented Sep 26, 2021

It still amazes me that this kind of collective discouragement and marginalization is tolerated. This issue is a prime example of the CEPC being worthless when it comes to chairs and members of the WG. A co-creator of Wasm once again not giving a proper answer and just closing the issue is the icing on the cake. This committee is completely broken.

@conrad-watt
Copy link

We spent many months discussing this decision (e.g. your presentation and @lukewagner's issue), and the outcome of the vote was clear.

This committee is completely broken.

Determining an overall consensus that allows us to move forward when members disagree is one of the necessary functions of the committee. In contrast, I think it would certainly be "broken" for us to spend our time revisiting an issue that we've discussed extensively and reached consensus on (in the absence of further evidence).

@Pauan
Copy link

Pauan commented Sep 26, 2021

@dcodeIO Dozens of experts (who are the most knowledgeable people in the world for JS and Wasm) disagree with you.

In that situation, you should consider that you might be wrong, instead of assuming that you are the only correct person in the world, and that everybody else are complete idiots (or malicious).

Making false accusations and insulting other people is against the Code of Conduct. You have insulted many people numerous times, and quite frankly I'm shocked that you are still allowed to continue your abrasive and unproductive behavior.

@dcodeIO
Copy link

dcodeIO commented Sep 26, 2021

Really, just more marginalization, manipulation and gaslighting? What a disgrace for the W3C and the Wasm community this is.

@dcodeIO
Copy link

dcodeIO commented Sep 26, 2021

Your comment is a great example of how this abuse works btw.:

Dozens of experts (who are the most knowledgeable people in the world for JS and Wasm) disagree with you.

In that situation, you should consider that you might be wrong, instead of assuming that you are the only correct person in the world, and that everybody else are complete idiots (or malicious).

Making false accusations and insulting other people is against the Code of Conduct. You have insulted many people numerous times, and quite frankly I'm shocked that you are still allowed to continue your abrasive and unproductive behavior.

Stating that the person...

  • ...is somehow lesser and that everyone else is more knowledgeable by affiliation - marginalizing them
  • ...would assume something obviously questionable they clearly don't - defaming them
  • ...would assume that everyone else is an "idiot" - laying an insult into their mouths
  • ...would violate the CoC while yourself are clearly violating it - reversing blame
  • ..had previously insulted many people which is simply not the case - gaslighting

So yeah, I repeat: It still amazes me that this kind of collective abuse is tolerated. This committee is completely broken and should be burned to the ground and rebuilt from the ashes, with chairs and a WG who are actually incentivized to uphold a minimum standard of principles and values, i.e. conflicts of interests reasonably accounted for. Right now this inherently hostile place only still exists because the abuse serves particular agendas, and triggering the bus factor, ideally through suicide I guess, to get rid of an unbeloved OSS project that would otherwise help to democratize the Wasm space is probably a nice bonus.

@conrad-watt
Copy link

@dcodeIO I also think the tone of @Pauan's comment could be improved, but I hope you can appreciate that your latest comment, especially the quote below, is on an entirely different level. We don't deserve this from you.

Right now this inherently hostile place only still exists because the abuse serves particular agendas, and triggering the bus factor, ideally through suicide I guess, to get rid of an unbeloved OSS project that would otherwise help to democratize the Wasm space is probably a nice bonus.

@dcodeIO
Copy link

dcodeIO commented Sep 26, 2021

It could be improved?! No, you absolutely deserve to know what constant reckless abuse over many years does to people. This is systematic failure of an entire technical body and you have been playing a significant part in it. 1 2 3

Your comment is a good example of how the more subtle form works btw.: At a glimpse it seems reasonable, but ultimately it is relativizing as if not much has happened to then shift the blame. Do something obviously wrong and then complain that the response hurt you, classic. Just a more clever form of gaslighting.

@dtig
Copy link
Member

dtig commented Sep 26, 2021

@dcodeIO Your responses here are a violation of the CoC.

  • As you've been reminded both over email as well as on github replies, personal attacks are not okay, and will not be tolerated in this community.
  • We've voted on the issues mentioned and reached consensus reached in this CG meeting, sustained disruption of discussion is unproductive.
  • As you are continuing to make repeated unsubstantiated claims of abuse, and are dissatisfied with the CG/WG as well as the chairs, you have other avenues to raise your concerns.

@Pauan I would also like to leave a note here that your response above is deregatory, regardless of the comments that prompted the reply.

Locking this issue as I don't expect this discussion to be productive.

@WebAssembly WebAssembly locked as too heated and limited conversation to collaborators Sep 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants