I’m looking at https://github.com/racket/racket/issues/3014 there was some good conversation around it but in the end it is not clear to me what the resolution should be. I can see one of these possible paths forward: 1. Document this behavior (where should it be documented though?) 2. Add string as a for-syntax provide from syntax/parse/define 3. Close out the issue (notabug, works as designed)

@samth: yes, my point is that assigned people are likely to forget or simply overlook the issue. I think it’s worth nudging to a degree (though I also understand that their work queue is probably overflowing already, with more important stuff)

I think one feature of GitHub that we might benefit from using it is milestone. It allows you to tag issues and PRs that you want to fix/merge in a release. This would give us a nice list to go over before each release. Of course, the milestone could change.

In a sense, the tag PR good to merge acts like milestone already, though it’s unclear when the tagged PRs will be merged. Milestone makes that aspect clearer.

Thanks for following up on this @sorawee

@samth is this expected behavior? https://github.com/racket/typed-racket/issues/959

In one sense yes

In another sense we should be able to fix it for ctypes

In a third sense the inability to do ffi in TR is a serious problem

not sure whether to label this a bug or not then

I agree

maybe let’s add a “known limitation” label? and also link this to some canonical issue tracking ffi support in TR?