January 07, 2023 Re: betterC and CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dennis | On 1/7/2023 3:53 AM, Dennis wrote: > On Saturday, 7 January 2023 at 02:09:00 UTC, Walter Bright wrote: >> For those that still suffer the slings and arrows from this problem, please let me know the bugzilla issues for them. > > I was actually working on a write up about BetterC and CTFE, and collected this list of issues: > > [Issue 18472 - [Reg 2.078] betterC: cannot use format at compile time](https://issues.dlang.org/show_bug.cgi?id=18472) > [Issue 19268 - BetterC turns off DRuntime for CTFE](https://issues.dlang.org/show_bug.cgi?id=19268) > [Issue 20095 - core.internal.convert.toUbyte doesn't work with -betterC](https://issues.dlang.org/show_bug.cgi?id=20095) > [Issue 20479 - octal integer literals don't work with BetterC mode](https://issues.dlang.org/show_bug.cgi?id=20479) > [Issue 21492 - betterC: TypeInfo is generated for code guarded by if(__ctfe) ](https://issues.dlang.org/show_bug.cgi?id=21492) > [Issue 23468 - [betterC] Cannot use std.array.join and std.algorithm.map at compile-time](https://issues.dlang.org/show_bug.cgi?id=23468) > Thanks, Dennis! I realized that there's a keyword for it, and here are the unresolved betterC-tagged issues: https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=betterC&keywords_type=allwords&list_id=243519&query_format=advanced 23468 wasn't tagged properly so I fixed it. |
January 07, 2023 Re: betterC and CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to Max Samukha | Thank you. I added a bugzilla for it: https://issues.dlang.org/show_bug.cgi?id=23606 In the future, I'd appreciate adding bugs to bugzilla, then linking to the issue in any n.g. discussion of it. |
January 09, 2023 Re: betterC and CTFE | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 7 January 2023 at 02:09:00 UTC, Walter Bright wrote:
> BetterC code does not have a GC, and so doesn't allow using the GC. But many have correctly pointed out that not having a GC cripples CTFE. CTFE should be able to use the GC, it's a major advantage of having a GC (and cripples languages with CTFE that don't have GC).
>
> So, making some experiments, I found it usually worked. Searching bugzilla, I found one case that didn't:
>
> https://issues.dlang.org/show_bug.cgi?id=20101
>
> and fixed it:
>
> https://github.com/dlang/dmd/pull/14789
>
> For those that still suffer the slings and arrows from this problem, please let me know the bugzilla issues for them.
>
> P.S. This also applies to @nogc code - CTFE should still be able to use the GC. Isn't that cool? Destroy the question "what good a GC is in a systems programming language!"
This is handy on embedded. Great work, Walter! :)
|
Copyright © 1999-2021 by the D Language Foundation