digitalmars.D.announce - Laser-D announcement
- Dibyendu Majumdar (14/14) Jul 28 Five years ago I started an attempt to define a subset of D
- monkyyy (5/8) Jul 28 pick 1, do you want ugly as sin permission to edit an const @live
- Kapendev (2/17) Jul 28 Why not use a style guide?
- user1234 (4/19) Jul 29 That looks like surface removal. For example with
- Dibyendu Majumdar (6/9) Jul 29 Hello, this is deliberate to allow easy merge of upstream. If the
- user1234 (4/16) Jul 29 OK so to summarize "create dead code on purpose". but thank for
- antonio (11/26) Jul 29 Interesting project and more coherent than "a subset of D" makes
- Dibyendu Majumdar (3/6) Jul 29 My thinking was that the parenthesis make it clear that its a
Five years ago I started an attempt to define a subset of D called Laser-D. See [this post](https://forum.dlang.org/post/hthnnctnivqzwzhjmwhi forum.dlang.org). Unfortunately at the time I was unable to continue as D is a pretty large language with many many features, and working through all that was too much effort. Now, with the help of Codex and Claude I have resumed the effort. The new effort is a more drastic reduction of D features; my guess is that many people will think it is too extreme. I am interested in opinions. Note that this is still very early - I intend to continue with this effort. https://github.com/CompilerProgramming/laser-d Regards Dibyendu
Jul 28
monkyyy <crazymonkyyy gmail.com> On Tuesday, 28 July 2026 at 22:52:39 UTC, Dibyendu Majumdar wrote:https://github.com/CompilerProgramming/laser-dThe syntax is less cluttered with annotations and qualifiers. explicit storage, control flow, function calls, and cleanup;pick 1, do you want ugly as sin permission to edit an const live contracted int where it becomes an engineering problem to get the compiler to understand "head const" or a doubly linked list, or can I just get access to the data?
Jul 28
On Tuesday, 28 July 2026 at 22:52:39 UTC, Dibyendu Majumdar wrote:Five years ago I started an attempt to define a subset of D called Laser-D. See [this post](https://forum.dlang.org/post/hthnnctnivqzwzhjmwhi forum.dlang.org). Unfortunately at the time I was unable to continue as D is a pretty large language with many many features, and working through all that was too much effort. Now, with the help of Codex and Claude I have resumed the effort. The new effort is a more drastic reduction of D features; my guess is that many people will think it is too extreme. I am interested in opinions. Note that this is still very early - I intend to continue with this effort. https://github.com/CompilerProgramming/laser-d Regards DibyenduWhy not use a style guide?
Jul 28
On Tuesday, 28 July 2026 at 22:52:39 UTC, Dibyendu Majumdar wrote:Five years ago I started an attempt to define a subset of D called Laser-D. See [this post](https://forum.dlang.org/post/hthnnctnivqzwzhjmwhi forum.dlang.org). Unfortunately at the time I was unable to continue as D is a pretty large language with many many features, and working through all that was too much effort. Now, with the help of Codex and Claude I have resumed the effort. The new effort is a more drastic reduction of D features; my guess is that many people will think it is too extreme. I am interested in opinions. Note that this is still very early - I intend to continue with this effort.That looks like surface removal. For example with https://github.com/dlang/dmd/commit/5ede0e9cf8775f366b3662d71989eea50c818e74, which aimed at removing UDAs, you just change the parser. The matching ast node declaration still exists. The matching semantics as well. Once consequence is that coverage of the compiler sources will get lower. Sorry but to me that does not look like serious work.https://github.com/CompilerProgramming/laser-d Regards Dibyendu
Jul 29
On Wednesday, 29 July 2026 at 17:22:07 UTC, user1234 wrote:That looks like surface removal. For example with https://github.com/dlang/dmd/commit/5ede0e9cf8775f366b3662d71989eea50c818e74, which aimed at removing UDAs, you just change the parser. The matching ast node declaration still exists. The matching semantics as well. Once consequence is that coverage of the compiler sources will get lower. Sorry but to me that does not look like serious work.Hello, this is deliberate to allow easy merge of upstream. If the front-end changes drastically then merging any upstream changes will be very difficult. So the strategy for now is to just disable features without changing AST and all.
Jul 29
On Wednesday, 29 July 2026 at 19:52:17 UTC, Dibyendu Majumdar wrote:On Wednesday, 29 July 2026 at 17:22:07 UTC, user1234 wrote:OK so to summarize "create dead code on purpose". but thank for your honnesty.That looks like surface removal. For example with https://github.com/dlang/dmd/commit/5ede0e9cf8775f366b3662d71989eea50c818e74, which aimed at removing UDAs, you just change the parser. The matching ast node declaration still exists. The matching semantics as well. Once consequence is that coverage of the compiler sources will get lower. Sorry but to me that does not look like serious work.Hello, this is deliberate to allow easy merge of upstream. If the front-end changes drastically then merging any upstream changes will be very difficult. So the strategy for now is to just disable features without changing AST and all.
Jul 29
On Tuesday, 28 July 2026 at 22:52:39 UTC, Dibyendu Majumdar wrote:Five years ago I started an attempt to define a subset of D called Laser-D. See [this post](https://forum.dlang.org/post/hthnnctnivqzwzhjmwhi forum.dlang.org). Unfortunately at the time I was unable to continue as D is a pretty large language with many many features, and working through all that was too much effort. Now, with the help of Codex and Claude I have resumed the effort. The new effort is a more drastic reduction of D features; my guess is that many people will think it is too extreme. I am interested in opinions. Note that this is still very early - I intend to continue with this effort. https://github.com/CompilerProgramming/laser-d Regards DibyenduInteresting project and more coherent than "a subset of D" makes it sound. Some of your rejected features are exactly why I use D, though: the GC and closures. Glad to see UFCS survived. Though with optional parentheses rejected, the chaining style loses some of its appeal. Was that trade-off deliberate? Also sorry to see `unittest` and contracts go: those were among the best parts of D for me. Time for Closure-D, I guess: the functional counterpart. :-)
Jul 29
On Wednesday, 29 July 2026 at 17:57:14 UTC, antonio wrote:Glad to see UFCS survived. Though with optional parentheses rejected, the chaining style loses some of its appeal. Was that trade-off deliberate?My thinking was that the parenthesis make it clear that its a function call and not field access.
Jul 29
On Wednesday, 29 July 2026 at 19:56:31 UTC, Dibyendu Majumdar wrote:On Wednesday, 29 July 2026 at 17:57:14 UTC, antonio wrote:Yes, but then we also have `object.thing`. The `object` could be a pointer or a simple value. My senior told me that being explicit is ALWAYS good, escpecially with the billion dollar mistake that are pointers, so I propose we change the pointer case to: `object->thing`. Much explicit. Very readable. A true C language successor.Glad to see UFCS survived. Though with optional parentheses rejected, the chaining style loses some of its appeal. Was that trade-off deliberate?My thinking was that the parenthesis make it clear that its a function call and not field access.
Jul 31
On Saturday, 1 August 2026 at 06:49:51 UTC, Kapendev wrote:On Wednesday, 29 July 2026 at 19:56:31 UTC, Dibyendu Majumdar wrote:Ignoring my above meme post, I do think that the `->` operator is not that bad. I can see why some C boomers would like it.On Wednesday, 29 July 2026 at 17:57:14 UTC, antonio wrote:Yes, but then we also have `object.thing`. The `object` could be a pointer or a simple value. My senior told me that being explicit is ALWAYS good, escpecially with the billion dollar mistake that are pointers, so I propose we change the pointer case to: `object->thing`. Much explicit. Very readable. A true C language successor.Glad to see UFCS survived. Though with optional parentheses rejected, the chaining style loses some of its appeal. Was that trade-off deliberate?My thinking was that the parenthesis make it clear that its a function call and not field access.
Jul 31