Why you're banning old syntax? Backwards compatibility is very important!
 

I don't know why you are doing this. I appreciate your effort in developing sourcemod. But you keep banning a lot of old syntax which is causing problems for a lot of coders.

Why is this required?

For example: Why the HELL are you planning to remove Array-based enum structs in 1.11. This is used in mostly all bigger plugins. When you want a massive change in enum, bring out enum2 and don't destroy 100 million lines of code using the previous enum.
Or this one: functag Why has this been removed? There is no reason for this besides there is another way to do it.

Backwards compatibility is MODERN! To destroy old code for getting a language which some great coders consider a "modern language" is the worst thing you could do to me.

Re: Why you're banning old syntax? Backwards compatibility is very important!
 

You can still use prior compiler versions?

The generated SP bytecode is forward-compatible with SP VM and hasn't seen breakage since 1.0 & 1.6?.

Re: Why you're banning old syntax? Backwards compatibility is very important!
 

tbh backwards compatibility slows forward progression. This is a main issue with python also, "what version do I need to run this script?" etc.
We were told about these changes for years and especially not to use array-based enum structs. It's kind of mindless work to convert from old syntax to new syntax now.

Re: Why you're banning old syntax? Backwards compatibility is very important!
 

At least we've got this.

Re: Why you're banning old syntax? Backwards compatibility is very important!
 

There have been quite a few source-code breaking changes in new major releases of SourceMod. As the language evolves, things must be removed in order to make any kind of forward progress. The main compatibility we put the upmost effort in maintaining is binary compatibility. For the most part, even the most ancient of plugins are still supported on the latest SourceMod build.

Re: Why you're banning old syntax? Backwards compatibility is very important!
 

Not much I can add here, since it's been said, but to reiterate: Yes, it's a pain. It sucks when stuff that worked stops working. It happens to me as a downstream developer on other projects, and I don't love it.

We work very hard on compatibility (something most projects do not do), which is why you can pull SM from 2006 and its plugins will probably still compile and work today. The amount of work to make Transitional Syntax happen - while still preserving the old declaration style - was insane. The parser is littered with dozens of mind-numbing hacks to make that work. I guarantee there are still bugs in it somewhere.

The number of people who actively work on SourcePawn is not zero, but it's less than 1, which is part of the tradeoff. Array-based enum structs were so poorly implemented and so under-specified that there was no feasible way I could keep them working while achieving other goals in my free time. Given I was able to add a straightforward replacement, and given you can use older compilers, I think it was a fair change to make.

If you're wondering, "what will break next?" Probably nothing. Array-based enum structs was the big baddie, and I think pretty much everything else in the language can be preserved going forward.

Re: Why you're banning old syntax? Backwards compatibility is very important!
 

@BAILOPAN I try to make a machine learning which is completely new zone to me, not sure if this is even achievable . Is it safe for me to to use the enum struck now or should I wait for proper oop style programming? I ll be on it in a month or two.

___________________
six eggs

Re: Why you're banning old syntax? Backwards compatibility is very important!
 

Enum structs are safe to use and the syntax is a lot better than the old array based ones.

Re: Why you're banning old syntax? Backwards compatibility is very important!
 

If the point of the question is about correct conversion to the new syntax, here are two examples of how to accomplish that (just compare with original).