Hmmm...

Code (edl) Select Expand


[x,y,z] = func()[1..3]


Code (edl) Select Expand


[0, x] = func();


Seems to imply that the first element should be 0. Just like this:

Code (edl) Select Expand


Array res = func();
assert(res[0] == 0);
x = res[1];


Prefix, postfix. I really don't care. It was just a proposal.

For further headaches:

Code (edl) Select Expand


int& x = ...;
int& y = ...;
[ x > 2 ? x : y] = func();


(Basically, what if instead of just variables it actually allowed any reference? Non-references would still be forbidden)

Here's my proposal.

1. If function returns a scalar, forbid [] syntax. Completely. It's worthless anyway.
2. If function returns Array, allow [] syntax but force the number of parameters to match.
3. If function returns Array but you don't want to use all parameters, use

Code (edl) Select Expand


[a, b, c, ...] = func();

Still, the array would be forced to have at least 3 elements.
4. If this is *still* not acceptable, you could have this:

Code (edl) Select Expand


[a, b?] = func();

or

Code (edl) Select Expand


[a, b=2]=func();

That code would work for func() returning both 1 or 2 parameters. It'd still be an error for 0 or more than 2 parameters (for 0, use a?. For more than 2, add the "...")

Code (edl) Select Expand


[a?, b?, ...] = func();

This is inspired by function arguments syntax.

As a final note, after an optional variable, all following variables must be optional. So this would still be an error:

Code (edl) Select Expand


[a?, b] = func(); //ERROR!


As an extra note, __unused could be used for worthless variables:

Code (edl) Select Expand


[__unused, x, __unused, __unused?, y?] = func();
cout << __unused << endl; //ERROR: __unused is not defined


If you dislike this syntax, this could also be used (although it might be more error-prone):

Code (edl) Select Expand


[, x, , ?, y?] = func();


Agree with

Code (edl) Select Expand


[x, y] = array_func();


Disagree with

Code (edl) Select Expand


[x, y] = scalar_func();


Well:

Code (edl) Select Expand


z_loop: for (int z = 0; z < 100; ++z) {
   y_loop: for (int y = 0; y < 100; ++y) {
      x_loop: for (int x = 0; x < 100; ++x) {
          break z_loop;
      }
   }
}

and

Code (edl) Select Expand


instance_loop: foreach (auto instance : instances) {
     adjacent_instances_loop: foreach (auto adjacent : instance.adjacent_instances()) {
         break instance_loop;
     }
}

Seems pretty clear to me.
Frankly, I'd generally avoid using integers for anything that can be reasonably named, but whatever.

Just remember: more features mean more test cases.

And regarding test cases, don't forget to add mixed loops/switch cases to your test suite.

I approve this concept. I've even thought about implementing this concept multiple times in my own game projects (although IIRC the idea never went ahead)

However, I'd change the API:

Code (edl) Select Expand


resource_group_id_t resource_group_load(string group_name);
void resource_group_unload(resource_group_id_t id);

resource_group_load_request_t resource_group_load_thread(string group_name);

//Wait for the loading to be finished.
resource_group_id_t request_group_thread_join(resource_group_load_request_t request_id);

//Tries to join, but does not hang if the loading is not done. Useful for loading screens.
bool request_group_thread_try_join(resource_group_load_request_t request_id, resource_group_id_t& group_id);


Feel free to change the type names (I just used these so the meaning would be easier to understand).

If a OO-style API is acceptable, then this could be further changed.

Yet one more reason to avoid numbered breaks: Some people might expect "start at 0" while others will expect "start at 1".

[error]

I voted named loops because it's less confusing, more intuitive and less error-prone.
Besides, it's the way Java does it so there are already precedents showing it can work.

Regarding the "error prone" part, imagine if you replaced that if case with a switch case. Then you'd have to change "break 2" to "break 3". Would you remember? That would be a pretty messy bug to track down. With named loops, there is no such problem.

Regarding warnings to "break 1". Why even allow it in the first place? Just ban it with a compile error. Problem solved. One less horrible feature to test.

The question to ask about "numbered breaks" is not "can we add it easily?", which I have no doubt you can if you can also do named loops. The real question is "what would this improve?". I can not think of any situation where numbered breaks would beat named breaks.

BTW: Just call the loop "outer_loop: for(...)"

TGMG has a massive testing platform running on it

Can't(in fact, shouldn't) you port it to other platforms too? I mean, wouldn't this testing platform also help finding platform-specific bugs that would otherwise not be found (since an OS X-only testing suite can't find Windows/Linux bugs)

Instead of running ENIGMA through Java, can't you just directly run the commands via command line (thus bypassing Java<->Valgrind interaction nightmares?)
Aside from that, you can always turn on all warning-related flags you can find.

If the file isn't too big, you can do things the classic gdb way. Jump into, Jump Into, Jump Out, etc.

Ah. In what way is this related to the JustDefineIt project? Also, is this C++-only or does this include the EDL language extensions(or whatever you call them)?

So what are the main differences between this new parser and the previous ones?

"Name a yellow fruit: "
I hope this accepts "apple" because yellow apples do exist.

"deleting spree". Doesn't git(and SVN, for that matter) keep a history that pretty much makes this sort of thing fixable in less than 5 minutes?

Couldn't you just go pick the previous versions of the deleted files on git (or your old SVN, if Rusky somehow broke git that badly), then add the missing files back to git so people who checked out git directly would have a working copy?