[BAILOPAN]

KyleS: I'm open to alternate proposals but they need to have really clear semantics so they're probably best taken offline, through PM or IRC. Yours looks identical to #3 but with the introduction of a pointer type and it's not really clear what that means. On face value it could mean one of three things: (1) It means proposal #2, except that the pointer can leak a value on the stack. (2) It means proposal #4, except with a * sigil instead of @. It means proposal #3, except it adds some kind of indirection.

In terms of reading and writing elements, dynamic arrays would act identically to the existing array types. I feel pretty strongly that dynamic arrays should coerce to old-style arrays, when calling functions, for maximum compatibility.

[BAILOPAN]

konichiwa - the & suggestion at face value looks like proposal #4 with a different sigil. Exposing internal references into arrays has a lot of problems that go beserk when you allow references to escape, so I dropped that idea early on. (We can take that discussion offline, if you're interested.)

[BAILOPAN]

A note re: syntax. I am interested in syntactic changes to proposal #3 that would preserve the type system. So far what I've heard is that people like the concept of #3 but the syntax is too weird and confusing, and I fully agree.

Otherwise, proposal #2 is probably the way to go, because we can build reference types on top of it (either through boxing, like proposal #4, or by wrapping arrays in object types).

[javalia]

to say about proposal 1, as dvander said on top, breaking existing sementics which has no problem at all.
and about the proposal 2, i will say again on below, but it also breaks existing sementics and language will get a runtime error which it cannot even catch in compile.
and the last, proposal 3, its tooooooooooooooooooooooooooooooo complex.
it`s Hierarchical pointer/non pointer(value) memory array is, to say, i cannot understand it even right now, and it feels like not a source pawn, but a source brain fuck.

sorry but all the proposal with reference type is too complex to me.

i just suggest to let us make a Explicit reference type which we can use in outside of function parameter, which must be assign it`s real target on it`s declation. while it lose proposal 3`s mad Hierarchical things, its very simple and can take 99% of programmer`s need(i cannot even imagine wut left 1 percent is)

new String:realone[*][255] = {some init};
new &String:bla[*][255] = realone;//legal
new &String:bla2[*][255];// fail at compile like "reference type must be inited on declare"

* keyword must still exist as a Explicit dynamic array type, so in function parameter we can deny Arguments in static array types to be passed into functions that needs dynamic array to be passed.

by the exist of explict dynamic array type notation, i am repeating dynamic array type notation by only []
is making a bad point in Semantics of language`s existing part

[Powerlord]

To be honest, the problem with all the proposals is it seems like we're trying to shoehorn concepts from other languages into Pawn where they don't really fit that well.

Perhaps instead of upgrading Pawn, we should just rewrite the syntax how we would like it to be?

(Note: It's been a while since I looked at the SourcePawn compiler's source code, so I have no idea how hard it would be to add, say... references and/or pointers to it)

[KyleS]

Originally Posted by Powerlord (Note: It's been a while since I looked at the SourcePawn compiler's source code, so I have no idea how hard it would be to add, say... references and/or pointers to it)

...

http://hg.alliedmods.net/sourcepawn2/

[Dr. Greg House]

Originally Posted by konichiwa I would like to suggest something similar to Proposal #3 but in a different approach, by introducing a generic reference type instead of limiting them to array only. // & as the reference operator new &g_Players[]; MakePlayerList() { new players[]; for (new i = 1; i <= MaxClients; i++) { if (IsClientInGame(i)) players += [i]; } // players (dynamic array) had to be allocated in heap and garbage collected // g_players (references) can be locally scoped g_Players = players; } This would have few interesting implications. // foreach loop with in-place update possible foreach (new i:&p in players) { if (IsClientTrolling(i)) { KickClient(i) p = 0 } } dv would most likely kill me for giving him more questions than answers though.

I like that idea very very much, especially the foreach with in-place update.

[BAILOPAN]

Dr. House - to avoid further discussion of that idea, I'll just say it's outright rejected ;) it's actually not useful and it breaks easily (consider the meaning of a reference bounded to an array that removes the element). It also creates aliasing that would inhibit compiler optimizations. It's actually faster to index into arrays than it is to use a pointer.

[Steell]

I actually really like Proposal #4, since it allows for ANY array to be assigned by-reference or by-value, as opposed to proposal 3 which, to my understanding, makes static-sized arrays assigned by value (requiring a copy) and dynamic-sized arrays assigned by reference.

However, in the interest of having a more unified syntax, I'd recommend Proposal #1. With #4, since arrays are passed to functions by-reference, array parameters should have the @ specifier to remain consistent. I think that's messy. With #1, everything is by-reference, which is much more consistent. If users want to copy arrays, they can use a copy function, something similar to strcopy.

[BAILOPAN]

Steell: Thanks for your feedback! Note that arrays will always be passed by reference to functions no matter what, so you don't have to worry about that. Proposal #4 is really just proposal #2, noting that we can extend the type system later to allow for higher-level references.