Syntax changes for Haxe 4

[Simn]

This is a collection issue for syntax changes we want to make for Haxe 4. Unless otherwise noted, all of these are "under discussion".

Short Lambda

See https://github.com/HaxeFoundation/haxe-evolution/blob/master/proposals/0002-arrow-functions.md (accepted)

is operator

See #2976 (accepted)

Improved asynchronous programming

Look into generators and async/await to find a good solution for Haxe.

Key-value iteration

See #2421

[Venryx]

Yes please! All four of these are great--especially the short lambdas. : D

(-dev interested in Haxe, coming from the world of C# and ES6)

[frabbit]

Not sure if it's a syntax change but typed meta (#3959) comes to my mind.

[ropwareJB]

Short Lambdas would be amazing.

Re: Asynchronous async/await: tink_await works really nicely

[RealyUniqueName]

Would be great to have something like this:

var value = getSomeValue();

if(value is MyType) {
    //value is typed as MyType in this block
    value.methodOfMyType();
}

switch(value) {
    case is MyType: //don't treat as syntax proposal :)
        //value is typed as MyType in this case
        value.methodOfMyType();
    case is AnotherType:
        //value is typed as AnotherType in this case
        value.methodOfAnotherType();
}

[jdonaldson]

moved to #5297

[Simn]

See #5297

[jdonaldson]

Regarding async programming mentioned above, I think we should build a first class shared api off of libuv.

Having an easily externable cross platform c library goes a long way towards unifying a lot of behavior quirks across platforms and languages.

[jdonaldson]

We should look into better support for continuations.

doSomething(function(a,b){
  doSomethingElse(a,b);
});

becomes

async k = doSomething();
doSomethingElse(k.a, k.b);

The async keyword here takes the last (typically callback) argument of a function, and then types itself as if it were a anonymous object of those arguments. (The Lua multireturn pattern should help here). Standard callback code is generated for the runtime.

I think it should be possible to handle this with try/catch support as well... each callback method body is wrapped in an error handler, which are all wired together.

This pattern won't work for all cases (including methods with more than one callback), but it should get rid of a good chunk of the indentation and error handling problems that crop up with async code.

[jdonaldson]

Introduce a val keyword for immutables.

[jdonaldson]

A data class type with tuple-style accessors (e.g. access by name or by position).

tuple Dog(name : String, age : Int);
[...]
var d : Dog = new Dog('fido', 4);
trace(d[1]); // fido
trace(d.name); // fido

[hughsando]

I would like inline-properties, like:

public var prop(function() return 3,null):Int

Should be easier now the name is fixed ('get_') and short lambdas.

[Justinfront]

jdonaldson should indexes start at 0 your example looks incorrect? Should it be?

var d : Dog = new Dog('fido', 4);
trace(d[0]); // fido

[nadako]

public var prop(function() return 3,null):Int

I think I like, this. Actually I proposed changing those get/set specifiers from simple idents to expressions, so stuff like this could be possible.

[fponticelli]

I like the prop proposal. Maybe there is no need for a full function? The signature of Getters/Setters is very well known so we could put in there just the body expression. In the case above:

public var prop(3,null):Int

One with a private var:

private var _prop: 
public var prop(_prop,_prop = _):Int

The _ is for value in the setter.

[Gama11]

I don't think using _ for that is a good idea, it's used for "ignored values" in other places. Maybe just value as a contextual keyword like in C#.

[jdonaldson]

@Justinfront you're right, start from 0. Too much time spent with Lua :)

[nadako]

I don't think using _ for that is a good idea, it's used for "ignored values" in other places. Maybe just value as a contextual keyword like in C#.

I'd say it's more correct to read that not as "ignored value", but as "some value here", considering how we use it in extractors within patterns (case _.toUpperCase() => "HI"). With this thinking, using _ like @fponticelli proposed makes sense IMO.

[Simn]

I would appreciate if you could handle discussions of a specific change in a distinct issue, else this issue is going to turn into a huge mess over the next weeks and months.

[jdonaldson]

Yeah, that's a good idea. But let's also give some kind of overview somewhere in a wiki page or something.

[Simn]

I'll just mention it in the entry-post here, it's intended as an overview anyway.

[harold-b]

Key-value iteration

Something to generate native javascript for( key in object ) loops without any additional overhead would be awesome.

This is the hack I've been using so far: https://gist.github.com/harold-b/df24fc5f77e316e2a3c684097256fc8c
Demo: http://try.haxe.org/#E9BC4

[back2dos]

@harold-b FWIW you can simplify that significantly: http://try.haxe.org/#453bA

[harold-b]

@back2dos Ooh, very nice! Didn't know it would inline a function body like that. Thanks for the tip. Think I'll use it like that instead.

Would still need an abstract for combined String/Int key array access though. Not to mention property deletion.

[RealyUniqueName]

Consider changing

class MyClass implements IFace1 implements IFace2 implements IFace3 {

to

class MyClass implements IFace1, IFace2, IFace3 {

E.g. I have a project, where such things is a common case:

class Joint extends Effect
    implements IBrightness
    implements IContrast
    implements ISaturation
    implements IHue
    implements IVertexColor
    implements IColorOffset
    implements IMask
    implements IYuvConversion
    implements IMultiTexture
    implements ISupplementedAlphaMerge
{

Such issue was discussed several years ago (#2972) and there was a message that it could be considered again on major version change.

[delahee]

I love everyone of those things.

On a more strategical side, imvho the 'async' is really a very important thing to secure in a very near future, it often floats in migrations discussions and other modern use cases.
Thanks!

[Simn]

There are distinct issues for the individual items here (except async which isn't gonna happen), so might as well close this.