Today's news comes a little early in the day, apropos of nothing. Although the real reason is, the afternoon is cut a little short and I don't know what to expect of that time block, so I'll probably be spending most of it on assessing an implementation path for various features.

This week has pulled me in a few different directions, but I've still kept more focus on the software. Late last week I got some changes in to support using the . operator to properly chain var and proc access after a proc call or a list lookup, and since I was already in the guts of the compiler I decided to use that momentum to add some new operators. BYOND 512 will now have ?. and ?: operators that are "null-safe"; that is, a?.b will simply be null if a is null. (Actually these operators are more true/false-safe; the real test being done isn't specific to nulls, but I don't care enough about the difference.) These operators can also be used in assignments, like a?.b = 1. A safe version of the list access operator has been requested too, although I'm on the fence about it because it's more complex. One important thing to note about these operators is that they're very efficient, because instead of having to do something like if(client && client.admin) you can simply say if(client?.admin) and the client var is only looked up once. In fact even the first proc call in BiggestMonster()?.KillPlayer() is only done once; you can now accomplish in one line of code what once took two or three.

I looked into the feasibility of adding cascade operators as well, like .. in Dart. That's a darn handy operator, because a..b()..c() is equivalent to a.b() followed by a.c()--except that if a is an expression, it's only evaluated once. I'm quite certain a cascade operator is doable. The problem I have is, that would mean implementing four operators: one that would be the type-insensitive : equivalent, and then null-safe versions of both. I'm not entirely thrilled with adding four new operators for that.

Raw strings are also in, and that was an interesting little project. The new raw strings come in three flavors, and they'll mainly be useful for large blocks of text that you don't want to include escapes in, and little bits of text like regular expressions where escapes are a pain in the butt to deal with. They're supported in .dms files too, but the tricky part is you'd have to have a 512 client to understand them. (One thing I haven't done yet is check on how .dms files are handled at compile time. I believe they're always parsed just to check on their validity, which means I should be able to set a flag requiring 512 clients.)

On the subject of language stuff, I've kind of had an itch for a while now to consider operator overloading. I think it's an idea whose time may have come. Many of the operators already have some level of datum awareness thanks to /matrix. The big trick here, I think, is making sure the path parsing stuff can recognize a keyword like "operator" and expect an operator to follow. But I'm going to let this percolate rather than pull me off course, because lots of other things are waiting in the wings.

But even though I'm spending time in the compiler guts, web work is not forgotten. In fact I had to touch some web stuff because the new raw string feature required an update to the syntax highlighting.

Today and probably a good part of next week I'm going to be doing some digging into 511 bug reports for the next maintenance release; although to be honest, more of that will be early next week because of time constraints, and also some of these are weird enough that they're gonna require me to wrap my head around finding a way to diagnose the problems.

Big thanks to everyone who's contributed to BYOND via Membership or donation this month. Now that April's nearly behind us, summer is about to come in full blast pretty soon. When it's too hot to go outside, it's a perfect time to stay in and play games. And in the meantime, you can still use the excuse of it being too rainy and cold until May gets its ducks in a row.
All this new syntax stuff is gunna be great I can barely wait.
Sounds like some cool things in the works!
One thing I forgot to mention is that ||= and &&= operators are on my list, but I won't approach those till I'm adding instructions because those will need new instructions. (The new operators I've done already would benefit from new instructions but don't necessarily need them. I plan to make that change in a future step.)

I have one open question regarding operator overloading, which is how to handle the index operator. Overloading [] for an LHS expression can't be done with a proc at this time, because there's no concept of pointers or passable references.
Are pointers even a possibility in DM?
In response to Ter13
Ter13 wrote:
Are pointers even a possibility in DM?

Currently no. What I would have to do to allow pointers would be to create a new refcounted object type that stores two references itself: base object and either var name or list index, along with info about whether it was a list or var access. There'd probably be more to it than that to support assignments/reads, and of course garbage collection would involve searching any active "pointer" objects for the object being deleted.
I like
The 'operator' keyword would definitely be perfect for operator overloading. Something very akin to C++'s approach.

It could even be useful for storing the path name as /datum/operator++ (for the increment operator) or anything else. Not only recognized by the compiler during the parsing process, but also recognized by Dream Seeker/Webclient during runtime.

As for indices, that one is a very interesting one to think about. Could try something akin to C# (which itself has the concept of indexers that often don't deal with pointers, but can use pointers in the unsafe context).