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

Deprecate LDIO #1567

Merged
merged 2 commits into from
Dec 5, 2024
Merged

Deprecate LDIO #1567

merged 2 commits into from
Dec 5, 2024

Conversation

Rangi42
Copy link
Contributor

@Rangi42 Rangi42 commented Dec 4, 2024

I already expect the results of our polls will be to deprecate ldio [...] but not ld [$ff00+...], so went ahead and implemented it in what should be an efficient way.

(In the test case, I know ld [$ff11], a and ld a, [$ff11] assemble to different opcodes than the rest; they're just there for completeness, and they illustrate b0495b3.)

@Rangi42 Rangi42 added enhancement Typically new features; lesser priority than bugs rgbasm This affects RGBASM labels Dec 4, 2024
@Rangi42 Rangi42 added this to the v0.9.0 milestone Dec 4, 2024
@Rangi42 Rangi42 requested a review from ISSOtm December 4, 2024 02:42
@Rangi42
Copy link
Contributor Author

Rangi42 commented Dec 4, 2024

Frankly it might be simpler to just remove, since that would let people do a one-line DEF ldio EQUS "ldh" "fix".

(The poll has zero votes for using ldio so far, and before today there were barely any mentions of it in gbdev, and most of those were wondering whether it's even supported by RGBDS or not.)

@vulcandth
Copy link

Unpopular opinion... Too much deprecation. I say just remove it, and let the assembler errors notify people they need to update their code. It's a simple replace anyways.. I know lots of people who ignore those deprecation warnings until a release causes it to stop building... And then they might just stay on the old version anyways.

Prepares for incoming rant :P

@Rangi42
Copy link
Contributor Author

Rangi42 commented Dec 4, 2024

Just to note, re: allowing multiple alternatives in general, we already do so for ld [hli/hld] aka ld [hl+/hl-] aka ldi/ldd [hl]. But unlike ldio, none of those is an obvious candidate for deprecation. (Even ldi/ldd get some use; they were explicitly requested in #73.)

@Rangi42
Copy link
Contributor Author

Rangi42 commented Dec 4, 2024

So far 13 votes to deprecate ldio vs just one to keep it; but 7 votes to keep ld [$ff00+c] vs 9 to deprecate.

Copy link
Member

@ISSOtm ISSOtm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, ldio is uncontroversial enough, so let's act it out. We'll see about the other syntax in a separate thread.

@Rangi42 Rangi42 merged commit 573e044 into gbdev:master Dec 5, 2024
22 checks passed
@Rangi42 Rangi42 deleted the deprecate-ldio branch December 5, 2024 17:49
@ISSOtm
Copy link
Member

ISSOtm commented Dec 5, 2024

Unpopular opinion... Too much deprecation. I say just remove it, and let the assembler errors notify people they need to update their code. It's a simple replace anyways.. I know lots of people who ignore those deprecation warnings until a release causes it to stop building... And then they might just stay on the old version anyways.

Oops, that was actually a good point, I think. Hmm, well, the main reason we're using deprecation warnings is to provide a nicer error message, so people who do upgrade are less confused and lost than getting a generic syntax error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Typically new features; lesser priority than bugs rgbasm This affects RGBASM
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants