Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: basic File I/O needs to work for --unicode-char:true #90

Open
davidcok opened this issue Feb 16, 2023 · 2 comments
Open

Request: basic File I/O needs to work for --unicode-char:true #90

davidcok opened this issue Feb 16, 2023 · 2 comments

Comments

@davidcok
Copy link
Collaborator

No description provided.

@alex-chew
Copy link
Contributor

@robin-aws I think it's possible for the file I/O externs to support both --unicode-char options at the same time. The exposed methods use string only for the file path parameter and the error message types (the read/written bytes are seq<bv8> and not string). Does the following approach make sense to you?

  • In target languages that support method overloading, like Java and C#, define a method overload for each compiled char type (char and Dafny.Rune in C#, or char and Dafny.CodePoint in Java)
  • In target languages that don't support method overloading but are dynamically typed, like JS and Python, branch on the path argument's type and return the error message (if applicable) as the same type
  • In Golang, define a union interface of the _dafny.Char and _dafny.CodePoint wrappers, and (like the JS/Python approach) branch on the argument's actual types (returning an appropriate error message type)

(Python and Golang aren't supported yet, but I want to check that this approach is feasible so we don't have to change our minds when we do add support.)

@davidcok
Copy link
Collaborator Author

OK - though the proof is in the doing.

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

No branches or pull requests

2 participants