> > Well, I suppose I have higher requirements than they have. From a
> > production-ready
> > compiler I would expect
> > – no (or at best very obscure) type errors to get through
> > – no compiler crashes
> > – no broken code generated
> > I don't think these are unreasonable criteria, yet valac fails all of them.
>
> Until now, we NEVER had only one of these problems. Weird.
>
> Honestly, we don't use 100.0% of all language features.
>
> Thats because we are creating a real and usable application we can sell
> to our customers and don't fiddle around with esoteric language features
> only for the purpose to be the one and only real Vala master ;-)
Well, apparently storing objects in a List is esoteric,
because the compiler will let obvious type errors pass:
var l1 = new ArrayList<Foo>();
ArrayList<Object> l2 = l1;
l2.add(new Object());
Foo f = l1[0]; // f has type Foo but points to an Object, no cast is needed.
And apparently creating a delegate that takes a generic type as an argument is
also esoteric, because that makes the compiler crash:
class Foo<T> {
public delegate void del(T t);
public del bla() {
return y => {};
}
}
Bindings to C functions with a generic type are obviously something only a
poser would do. Surely that's the only reason why simple_generics was added:
[CCode(simple_generics = true)]
extern GLib.HashTable<K, V> g_hash_table_ref<K, V>(GLib.HashTable<K, V> ht);
Calls to a function defined like this will lead to broken C code being
generated.
Obviously all these examples are completely contrived, academic and serve no
purpose other than showing off my 31337 comp!l0r h4xx0ring 5k!11z. Thanks for
finally showing me the light about the One True Programming Language: Vala!
_______________________________________________
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
