search

waneck / testrepo

0 stars 0 forks source link

Issue 1448 - ECheckType syntax - haxe #1448

Open waneck opened 11 years ago

waneck commented 11 years ago

[Google Issue #1448 : http://code.google.com/haxe/issues/detail?id=1448] by ncanna...@gmail.com, at 2013-02-04T19:49:52.000Z Study whether adding "expr : Type" as a concrete syntax for ECheckType creates issue or not.

This can be used to help/check type inference as well as in macros.

waneck commented 11 years ago

[comment from si...@haxe.org, published at 2013-02-04T20:17:32.000Z] I'm in favor of this, it could alleviate Array transition pain.

We would have to solve the syntax ambiguity with ternary operator though.

waneck commented 11 years ago

[comment from si...@haxe.org, published at 2013-02-07T17:41:06.000Z] I can't see how this would work out while the ?: operator is around, unless the parser is made case-sensitive, which is surely not worth it.

waneck commented 11 years ago

[comment from si...@haxe.org, published at 2013-02-08T00:30:49.000Z] Juraj's suggestion of making parentheses mandatory for this seems to work nicely. We might have to check a few places where certain AST nodes are expected because these could now be wrapped with ECheckType, but then the same has always been true for EParentheses.

waneck commented 11 years ago

[comment from si...@haxe.org, published at 2013-02-09T19:12:48.000Z]

waneck commented 11 years ago

[comment from heinz.ho...@googlemail.com, published at 2013-02-11T10:55:43.000Z] How about making this syntax context dependent, which means whenever you're between ? and : of the ternary operator checktype syntax can only be used with parenthesis. But in every other case you can use it without them (which is good). This way the parenthesis are only required when using a combination of ternary and checktype, which is imho a rare use case.

waneck commented 11 years ago

[comment from si...@haxe.org, published at 2013-02-18T00:47:04.000Z]

waneck commented 11 years ago

[comment from si...@haxe.org, published at 2013-02-24T17:12:14.000Z]

waneck commented 11 years ago

[comment from heinz.ho...@googlemail.com, published at 2013-03-01T13:06:02.000Z] I hope that the ECheckType syntax allows no op casting without loosing the type of the expression in macros.

To build my type class library i have to do some unsafe casts (no op) to fake type constructor polymorphism. The problem is that the expression type of an inlined expression is lost when entering a macro.

// really stupid example

public static inline function noOpCast (x:Dynamic):Array { return cast x } var d : Dynamic = [1,2]; noOpCast(d).myUsingMacro(); // noOpCast(d) becomes cast d and the type Array is lost.

Would it be possible to use ECheckType like this without loosing the expression type

public static inline function noOpCast (x:Dynamic):Array { return (cast x : Array); }

noOpCast(d).myUsingMacro(); // noOpCast(d) is hopefully ECheckType( cast d, Array) at this point.

waneck commented 11 years ago

[comment from lucadelt...@googlemail.com, published at 2013-04-16T22:32:40.000Z] Is this another problem which would be solved with ECheckType?

class Test { static inline var X:Float = 65535; static inline var Y:Float = 65535.0; static function main(){ trace(X_X_X_X); trace(Y_Y_Y_Y); } }

since X is inlined, and the literal value is inferred as Int, the expression X_X_X*X uses integer multiplication and gives negative value whilst the Y case correctly uses the literal as a float.

I presume that with ECheckType, this would be compilable like: ECheckType(65535, Float)*ECheckType(65535, Float)... and give the expected result.