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

Fixes to breaking changes in C3 0.6 -> 0.7: #61

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

lerno
Copy link

@lerno lerno commented Mar 3, 2025

Because 0.7 has breaking changes compared to 0.6.x I'm offering this pull request to be used if you want to upgrade to use the C3 master branch.

I understand you mostly don't do any work with C3 recently, so feel free to ignore this pull request.

Changes are:

  1. Changed generic syntax from (< >) to { }
  2. HashMap and List now (from 0.7.0) default to the temp allocator instead of the heap allocator. This makes sense for casual use in functions, but for the Koil code the assumption was that they would heap allocate, the solution is that globals are initialized to map::ONHEAP and list::ONHEAP respectively, which will default to heap when first used. This allows the code to mostly be unchanged and not need an explicit .init() of the globals. The exception is scene where it seemed more natural to do an explicit init(mem).

1. Changed generic syntax from (< >) to { }
2. HashMap and List now default to the temp allocator instead of the heap allocator. This makes sense for casual use, but for the Koil code the assumption was that they would heap allocate, so globals are initialized to map::ONHEAP and list::ONHEAP which will default to heap when first used. This allows the code to mostly be unchanged and not need an explicit .init() of the globals. The exception is `scene` where it seemed more natural to do an explicit `init(mem)`.
@nikpivkin
Copy link

Hi @lerno !

I'm curious, what was the reasoning behind the syntax change for generics?

@lerno
Copy link
Author

lerno commented Mar 5, 2025

I felt that the Foo(<int>) syntax felt overly heavy and opaque. Foo<int> has severe problems when it comes to lexing and parsing. Foo(int) and Foo[int] struggles with ambiguities. A test with Foo<[int]> which was probably the best alternative with two tokens in a row I could find. Foo {int} is fairly lightweight and looks more like a finished syntax. For functions and such it's not great but foo::bar(<int>)(123) still feel clunky compared to foo::bar{int}(123).

I always wanted to find an alternative to (<>), but it has taken until now to find a candidate.

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

Successfully merging this pull request may close these issues.

None yet

2 participants