Matan Lurey

I am now running at `Dart VM version: 2.0.0-dev.14.0 (Unknown timestamp) on "linux_x64"` ... and will update this thread if the problem goes away.

Nope, still got a crash :-/

+1 We also wouldn't need `@Injectable` at all for a `class`, as the only reason it will exists (soon) is to generate a factory function once per library versus once...

_Or it would be nice if you could just infer, but I understand if we cannot_

Why isn't that expected to happen? The above is a contrived case, but patterns like this are common enough: ```dart if (foo?.isDelicious() == true) { print(foo.describeDeliciousness()); } ```

Respectfully whether you personally want to reason about it isn't really the point of this issue - at least me and Stephen (likely more) consider this valid. I suspect this...

Totally! I could also see at minimum adding some information to our migration guides (/cc @munificent) that highlight "these are cases you'd think would promote, but don't, here are some...

> Can't dynamic dispatch to `writeLog` be implemented as a wrapper on top of the two functions? It could. It does mean though, for overloads at least, you do not...

Thanks @munificent. I agree this is probably a few issues and needs more investigation. Without a longer reply, my 2 cents: * Dynamic overloading is _cool_, but not necessary. With...

@lrhn: > If you could overload methods, tear-offs would no longer work. You already cannot tear off what users write instead of overloads, which is multiple methods: ```dart class Foo...