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

Jump to bottom

Cleanup camlinternalFormat #6458

Closed
vicuna opened this issue Jun 16, 2014 · 5 comments
Closed

Cleanup camlinternalFormat #6458

vicuna opened this issue Jun 16, 2014 · 5 comments
Labels
feature-wish stdlib

Comments

@vicuna
Copy link

vicuna commented Jun 16, 2014 •
edited by nojb

Original bug ID: 6458
Reporter: @alainfrisch
Status: feedback (set by @damiendoligez on 2014-07-16T14:11:26Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.02.0+beta1 / +rc1
Category: standard library
Monitored by: @jmeber @yallop

Bug description

This module does not seem as "internal" as other camlinternalModules. In particular, the make_printf function and the acc type could very well, and quite simply, be used in client code. Actually, I don't think the compiler generate references to this module.

It seems its interface could be cleaned up quite a bit. All char_set related functions seem to be used purely internally. heter_list could go to scanf.

What about renaming the module to Format_strings, and drop its "internal" status?
@vicuna
Copy link
Author

vicuna commented Jul 16, 2014

Comment author: @damiendoligez

What is "internal" about this module is that it is subject to change without notice and without much consideration of backward compatibility. What you are asking for is legitimate but it has a cost in terms of maintenance burden.

I think we should at least wait until the module has become quite stable.

@vicuna
Copy link
Author

vicuna commented Jul 16, 2014

Comment author: @alainfrisch

I'm certainly not asking for any compatibility guarantee, but I see a difference between internal (==> to be used by the compiler/stdlib only) and likely to change in the future (==> there are legitimate uses, but use at your own risk).

@github-actions
Copy link

github-actions bot commented Apr 9, 2021

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Apr 9, 2021
@gasche gasche removed the Stale label Apr 9, 2021
@gasche
Copy link
Member

gasche commented Apr 9, 2021

@alainfrisch a new opinion on this PR after a while? It's not bad, but not terribly exciting either, so I would not personally do the work unless there is a clear use-case.

@alainfrisch
Copy link
Contributor

Yeah, no, let's close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature-wish stdlib
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gasche @alainfrisch @vicuna