[BAILOPAN]

That might seem confusing but look at it this way: view_as<> will never take something that is *not* a tag. If we ever add types like "double", or "int64", those will not be tags, and they will not be valid inputs to view_as<>. Another example, "char[]" is a type, not a tag. view_as<> won't accept that.

[Miu]

Originally Posted by BAILOPAN @Miu: If you're asking for whether there will be operator overloading (the only way I can imagine non-intrinsic implicit casts), those already exist. But they're deprecated since they're based on tags, not types. A replacement is pretty far off, there's bigger fish to fry in the interim.

No, I'm asking if it will ever be the case that you can do float f = 1; and f will hold 0x3F800000 in memory rather than 0x00000001. I don't know how to make it any simpler than that.

But since that'd ruin backwards compatibility (although it doesn't seem like a big deal since it produces a warning), I was more curious if there'd be explicit casts, as in (bool)1.0. Or even cast_as<bool>(1.0) or something insanely ugly like that. You can do some logical operator like !!1.0 or 1.0 != 0.0 to get a bool, and maybe put that in some bool() macro or w/e so it doesn't look completely stupid, but there's no way to cast it naturally. These seem very simple to implement, at least for native types, and it's really weird that your language doesn't have them.

[asherkin]

SourcePawn is on the road to sane semantics (which is the whole point of this thread), the crazy tag mess is inherited from Pawn (which didn't have float support at all back when it was forked). The float stuff was shoehorned in a long, long time ago (hence the Float tag having a capitalised name).

bool is not a type in SourcePawn (yet), it's just a tag name for convenience (think C, pre C99, where every lib had a BOOL typedef). The new syntax looks like real types to help the transition along, but it all maps back to the same quirky system.

[BAILOPAN]

Originally Posted by Miu No, I'm asking if it will ever be the case that you can do float f = 1; and f will hold 0x3F800000 in memory rather than 0x00000001. I don't know how to make it any simpler than that.

Okay, this is a much more specific question. "float f = 1" is not valid in SourcePawn. It should present either a type error or (unfortunately, more likely the case) a tag warning.

Thus there shouldn't really be any compatibility issue with introducing an intrinsic promotion. I believe AMX Mod X already does this for assignment.

Originally Posted by Miu These seem very simple to implement, at least for native types, and it's really weird that your language doesn't have them.

Given the data you have, it might seem like an easy problem. I hope that your careful reading of the transitional syntax documentation (this thread, and the wiki page) - as well as the source code - reveals the history and current state of the language. Then, if you still view this as a very simple task, patches are absolutely welcome. (EDIT: With the caveat that semantic/grammatical changes need be vetted as future-proof first.)

[Miu]

Originally Posted by BAILOPAN Okay, this is a much more specific question. "float f = 1" is not valid in SourcePawn. It should present either a type error or (unfortunately, more likely the case) a tag warning.

No, it was a concrete example of the general principle that you have something that takes T1, you feed it T2, the compiler notices a legal implicit conversion T2->T1, and does it. Maybe it gives a warning about loss if it's a demotion. Implementing it only for certain operations is only partial implicit casting.

I can see that it's not valid. I'm asking if things like that will be valid eventually. It's valid C, valid C++, valid C# and valid Java!

Originally Posted by BAILOPAN Given the data you have, it might seem like an easy problem. I hope that your careful reading of the transitional syntax documentation (this thread, and the wiki page) - as well as the source code - reveals the history and current state of the language. Then, if you still view this as a very simple task, patches are absolutely welcome. (EDIT: With the caveat that semantic/grammatical changes need be vetted as future-proof first.)

What am I missing? What is the issue with having (type)x evaluate to a some simple conversion of native types?

[BAILOPAN]

To answer your question about explicit casts, the issue is the compiler's design. It has no concept of types, and no syntax tree, so implementing anything tends to either be impossible or have very convoluted/invasive solutions. A very narrow cast expression with the grammar "(" tag-identifier ")" expr is probably doable - getting to type-expression instead of tag-identifier would be a lot harder. The allowed conversions of even tag-identifier would have to be hardcoded, and any new features involving floats would need a new binary version (or some special-case hack to avoid adding a new JIT opcode).

[RedSword]

Originally Posted by BAILOPAN That might seem confusing but look at it this way: view_as<> will never take something that is *not* a tag. If we ever add types like "double", or "int64", those will not be tags, and they will not be valid inputs to view_as<>. Another example, "char[]" is a type, not a tag. view_as<> won't accept that.

Amongst other : admin-sql-thread.sp, line 380 :

user_lookup[total_users][1] = view_as<int>(adm);

"int" isn't a tag (but a tag-type "equivalent" if I'm right). Should that code be wrong ?

[BAILOPAN]

"int" is designed to be interchangeable with the "_" tag. There's special code littered about the compiler to make sure they resolve to the same thing.

view_as<> will not work when the type does not have an equivalent tag. For example, "char[]" is a type, but does not exist as a tag. If we add real objects, those types will not work as tags. Similarly something like int64/double would not work on a tag, since tags are designed for 32-bit cells.

[BAILOPAN]

In the current compiler, we parse something like "char x[]" or "int" or "Float:" into a temporary object describing the entire type (called a typeinfo_t). However, all of the existing types have tag equivalences, so this object gets reduced to a single tag and then some information about the array dimensions.

In the v2 mockup compiler, it's a little different. Everything is parsed and resolved into a real type (a TypeExpr, that holds either a Type object or a TypeDescriptor), and there are very specific rules for how types behave. In this model the tag system is almost completely gone, since we can emulate it using types. There is one caveat:

PHP Code:

new Egg:numEggs = Egg:5
Clam numClams; 


The first line is valid SourcePawn, since "Egg" is just a tag and tags really don't have any semantic meaning. Tags come into existence simply by using them. The second line, however, is invalid. New-style syntax requires types, and no "Clam" type has been declared.

To preserve this behavior the v2 mockup compiler has to remember which names were used as tags, but never declared as a type. It then creates empty enum types for each of those tags.

EDIT: A final differentiation between tags and types, is that user-created tags have different semantics if they start with a lower-case letter. The coercion rules are relaxed in some circumstances. This won't be preserved in the future.

[m_bNightstalker]

native int GetSpawnPoint(int index, float &point[3]);

error 067: variable cannot be both a reference and an array (variable "point")

Whats wrong here guys?