[nergal]

Is there anything regarding Natives and Forwards with the new API and syntax?

What about the old native rule where you can't return a float? Do they still require the _: empty tag to return a float?

[Powerlord]

Should I assume it's not possible to have a char[] property at the moment, seeing as how they have a different syntax for get than other types?

[asherkin]

Originally Posted by nergal Is there anything regarding Natives and Forwards with the new API and syntax? What about the old native rule where you can't return a float? Do they still require the _: empty tag to return a float?

Reposting it doesn't make either of your questions make any more sense.

[BAILOPAN]

@nergal: I don't understand the first question, so the answer is probably "no". The second question is a non-sequitur, there has never been a rule that natives can't return floats. You might be referring to the fact that some natives (like GetArrayCell) have untyped returns, which is something we did mostly for own convenience (rather than have GetArrayInt, GetArrayFloat, etc). It's not great, certainly.

@Powerlord: I don't understand what you mean by "different syntax". The syntax for type-expression parsing is fairly well-formed, it's just that the types on the get/set methods are chosen for you, so you don't get to specify them again. In the getter case, it's the type-expr of the property, in the setter case, the return type is void. But, natives cannot return arrays yet, so it would be difficult to construct a useful property getter that returns an array. I think you could probably do a setter though.

Also note that even though setters return void, that doesn't affect assign-exprs. For example, (x = (a.b = c)), if |a.b| is a setter (therefore returning void), the result of the assignment expression is always |c|. So I actually have no idea what would happen if you did that with an array-setter the compiler's handling of arrays is fairly tricky.

[nergal]

Originally Posted by asherkin Reposting it doesn't make either of your questions make any more sense.

Will the natives and/or forwards system get a make over in the transitional API?

Also, will natives, that are supposed to return floats, require the _: empty tag like with the old Syntax and API?

Like this

PHP Code:

new Float:DamageResistance[MAXPLAYERS+1];
public Native_GetArmorDamageResistance(Handle:plugin, numParams) 
{ 
    return _:DamageResistance[GetNativeCell(1)]; 
} 


[Wliu]

In addition to what nergal said, is there any chance that we'll be able to return Strings instead of modifying the arrays that were passed to the native/function?
eg `someString=ThisReturnsAString();` vs `ThisReturnsAString(someString, sizeof(someString));`

[BAILOPAN]

No, nothing about that is changing. Everything in functions.inc is the result of fundamental design flaws in the Pawn VM, so it's unlikely anything syntactically significant will happen to it. With any luck Pawn will eventually be at a point where all of the gross native/fn invocation gunk can go away.

The fundamental reason is that Pawn plugins are sandboxed because the underlying VM has no way to identify memory bounds on arrays (and therefore you could go out-of-bounds and corrupt memory outside the plugin). When calling from one plugin into another, the memory has to be copied and translated into the destination plugin's address space for it to be readable. If we can put bounds on arrays and unify address spaces, we can remove that restriction, and functions.inc would be obsolete.

It's a long road to get there (we need a new binary format), but that's what I'm looking toward.

[BAILOPAN]

@Wliu - I just realized I could actually get this working, but for natives only (edit). If that seems okay, file a bug.

[Powerlord]

Originally Posted by BAILOPAN @Powerlord: I don't understand what you mean by "different syntax". The syntax for type-expression parsing is fairly well-formed, it's just that the types on the get/set methods are chosen for you, so you don't get to specify them again. In the getter case, it's the type-expr of the property, in the setter case, the return type is void. But, natives cannot return arrays yet, so it would be difficult to construct a useful property getter that returns an array. I think you could probably do a setter though.

By different syntax, I mean this:

Originally Posted by Wliu ThisReturnsAString(someString, sizeof(someString));

...which is different from normal getters, which would just return the value.

(Incidentally, Wilu, this is BBCode not Markdown)

[BAILOPAN]

@Powerlord: Not sure what you're asking then, but yes given that the prototype of a getter must be a function that takes a single "this" parameter and returns a non-void type, that would not qualify as a valid getter.