Hi All,
After letting the new syntax make its rounds, there are a few adjustments I'd like to make. Nothing new in this post, only removals (sorry!)
Intrinsic Handle
Handle will no longer have a methodmap in
handles.inc. It will be a compiler intrinsic. You will still be able to
delete and
Close() it (although
Clone has been removed as a method).
Removing Destructors
These were intended for extensions, but they were difficult to support in the language without exposing terrible things (like, potentially, object resurrection if we ever do GC). Instead, destructors will go away entirely. You can still use
delete on Handles because they're now intrinsic.
Neutering __nullable__
For such an important piece of future type system sanity, this one was a pretty bad leak. It was undocumented but that didn't stop people from creating alternate nullable systems that violated its intended semantics.
__nullable__ will still allow using
new with custom constructors, but it won't allow comparing to
null.
Removing () = binding
When we were first prototyping methodmaps, we added a shortcut method declaration syntax, called "method binding". It looks like this:
NewMethod () = OldMethod. This syntax is incredibly annoying to support in the compiler, and our docgen tools don't support it at all. Our own usage of it is almost gone in the 1.7 branch.
So, I will attempt to just remove it entirely in 1.8. There are three ways to fix up your methodmaps. One is to just write wrapper functions that call the old function. Two is to just delete the old function and move any lingering code into methodmap-land. Finally, if you are an extension, you can create another native binding. For example,
PHP Code:
// C++...
{ "CreateRegex", CreateRegex },
// Pawn
native CreateRegex();
methodmap Regex {
public native Regex() = CreateRegex;
You can instead do:
PHP Code:
// C++...
{ "CreateRegex", CreateRegex },
{ "Regex.Regex", CreateRegex },
// Pawn
methodmap Regex {
public native Regex();
(This change will definitely not be backported to 1.7.)
Requiring parens on view_as<>
A mistake in the implementation of
view_as<> allowed using it without parenthesizing the affected expression. This has been fixed already on 1.8.