Re: New API and Syntax
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.
|
Re: New API and Syntax
Quote:
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. |
Re: New API and Syntax
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. |
Re: New API and Syntax
Quote:
Thus there shouldn't really be any compatibility issue with introducing an intrinsic promotion. I believe AMX Mod X already does this for assignment. Quote:
|
Re: New API and Syntax
Quote:
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! Quote:
|
Re: New API and Syntax
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).
|
Re: New API and Syntax
Quote:
Code:
user_lookup[total_users][1] = view_as<int>(adm); |
Re: New API and Syntax
"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. |
Re: New API and Syntax
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:
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. |
Re: New API and Syntax
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? |
| All times are GMT -4. The time now is 22:24. |
Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.