I've just noticed that a simple for (key in someMapping.keys()) ... generates over 2 kb of code.
The reason being that Mapping's getCondensed is declared as inline.

I've looked at List and it uses inline sparingly (even there, exists and count can be considered for un-inlining).
However in Mapping, basically every function is inlined, getCondensed seeming to me the most egregious abuse of inline.

Was there any benchmarking or real-world code profiling done on these data structures, to determine what deserves to be inlined, and what doesn't? If not, I propose to remove inline from everything over 1-3 lines of code.

Let's say we have incoming data where we expect List and that is parsed like this:

function transform(data:Test) {
	trace(data);
	trace(data.l);
	trace(data.l.iterator());
	for (m in data.l) trace(m);
}
var incoming = haxe.Json.parse('{"l":""}');
transform(incoming);

...
typedef Test = {
	var l(default, never):tink.pure.List<String>;
}

Following will output:
src/MainClient.hx:7: { l: '' }
src/MainClient.hx:8:
src/MainClient.hx:9: { list: [ '' ] }
and then crash:
TypeError: Cannot read property 'length' of undefined at tink_pure_NodeIterator.next

Currently array comprehension will invoke ofArray does a .copy() call, which is unnecessary

var a:Vector<Int> = [for(i in 0...2) i];

generates:

var _g = [];
_g.push(0);
_g.push(1);
var this1 = _g.slice();

I guess the reason is that typeExpr will convert a EArrayDecl into some "init+push" instructions does breaking the switch. I wonder why if we can't just rely on EArrayDecl instead of TArrayDecl in the first case?

Currently it is serialized as Array<MapEntry> which could be containing redundant info.

A better representation would be Map in the serialized form = Array<Tuple>

But somehow I couldn't make the compiler to accept that.

class Main {
	static function main() {
		final v:tink.pure.Vector<Int> = [1,2];
		switch v {
			case [1,2]: true;
			case _: false;
		}
	}
}

with -v:

...
Typing macro tink.pure._Vector.Vector_Impl_._new
Typing macro tink.pure._Vector.Vector_Impl_.unwrap
Typing macro tink.pure._Vector.Vector_Impl_.get
Typing macro tink.pure._Vector.Vector_Impl_.map
Typing macro tink.pure._Vector.Vector_Impl_.filter
Typing macro tink.pure._Vector.Vector_Impl_.sorted
Typing macro tink.pure._Vector.Vector_Impl_.concat
Typing macro tink.pure._Vector.Vector_Impl_.lconcat
Typing macro tink.pure._Vector.Vector_Impl_.fromVector
Typing macro tink.pure._Vector.Vector_Impl_.fromArray
Typing macro tink.pure._Vector.Vector_Impl_.fromMutable
Typing macro tink.pure._Vector.Vector_Impl_.fromIterable
Typing macro tink.pure._Vector.Vector_Impl_.toArray
Typing macro tink.pure._Vector.Vector_Impl_.ofAny
Typing macro tink.pure._Vector.Vectorlike_Impl_.ofSingle
Calling macro tink.pure._Vector.Vector_Impl_.ofAny (src/Main.hx:5)
Exiting macro tink.pure._Vector.Vector_Impl_.ofAny
Typing tink.pure._Vector.Vector_Impl_._new

Is tink_pure ready to be used in real projects (if it is, you may want to fix the 404 link on https://lib.haxe.org/p/tink_pure/)?
Also, I'm interested in how it compares with things like immutable.js or clojure's persistent data structures.

It may be useful to document some of this things in a README file.

From Gitter:

Kevin Leung @kevinresol 17:58
btw is there no quick way to get the last item in a list, except iterating it to the end?
tink_pure list I mean

Juraj Kirchheim @back2dos 18:10
nah, not really
we could track it of course
it adds a little bit of overhead, but I guess that'd be fine
just add a last field to Node that's also required in the constructor and fix the ensuing compiler errors and it should work
(and expose it on the List of course)

Haxe 4.2.5

var data:tink.pure.Vector<{final whatever:Int;}> = tink.pure.Vector.fromArray([{whatever:42}]);

this gives following compilation error:

src/MainClient.hx:31: characters 47-90 : error: Cannot unify final and non-final fields
src/MainClient.hx:31: characters 47-90 : ... have: tink.pure.Vector<{ whatever: Dynamic }>
src/MainClient.hx:31: characters 47-90 : ... want: tink.pure.Vector<{ whatever: Dynamic }>
src/MainClient.hx:31: characters 47-90 : ... For function argument 'compute'
src/MainClient.hx:31: characters 47-90 : ... For function argument 'fn'

Using List instead of Vector fixes the problem.

class Main {
	static function main() {
		var foo:tink.pure.Vector<Foo> = [];
		var bar:tink.pure.Vector<Bar> = foo;
	}
}

typedef Foo = {
	final id:String;
	final ?project:String;
}

typedef Bar = {
	final id:String;
	final createDate:Date;
}

The above code compiles but it should not.

If we replace Vector with Array we will get:

src/Main.hx:4: characters 3-28 : error: { id : String, createDate : Date } has no field project
src/Main.hx:4: characters 3-28 : ... have: Array<Foo>
src/Main.hx:4: characters 3-28 : ... want: Array<Bar>

It would be nice to see Mapping improve one day.
Currently it leaks memory when a same key is added to it.
E.g. this code would result in a mapping that works correctly, but it's underlying list has 4 elements:

		var m:Mapping<String, String> = null;
		m = m.with("a", "1");
		m = m.with("b", "2");
		m = m.with("a", "3");
		m = m.with("a", "4");

Reduced SliceTest iterations from 100 to 20: 9707721

Failure caused by this commit: c9efe76

Log: https://travis-ci.org/haxetink/tink_pure/jobs/426110645#L612

Very likely there are some problem in tink_streams. (the overflow comes from Generator#forEach)