Scala's `new` syntax is an anomaly. I'd rather say `new[Foo](x, y, z)`, or just `new(x, y, z)` if `Foo` is the expected type.
-
-
Replying to @propensive
@propensive TBH I am more and more against `new` at all, since it precludes instance reuse. (i.e. only makes sense for mutability)2 replies 1 retweet 0 likes -
Replying to @viktorklang
@viktorklang Particular thing that gets me is the precedence of dot vs space in, e.g., `new Foo().bar`.2 replies 0 retweets 0 likes -
Replying to @propensive
@propensive Oh yes! I still, out of habit and expecation, always surround it with its paren(t)s. `(new Foo).bar`1 reply 0 retweets 0 likes -
Replying to @viktorklang
@viktorklang Yeah, that's nice and unambiguous. Just seems a bit clunky...1 reply 0 retweets 0 likes -
Replying to @propensive
@propensive Absolutely. Thinking of which, you could most probably create an `alloc` macro to allow for: `val foo = alloc[Foo](bar, baz)`1 reply 0 retweets 0 likes -
Replying to @viktorklang
@viktorklang Yes, that's what I wanted to do.@xeno_by said I couldn't access the expected type, so `alloc(bar, baz): Foo` would never work.1 reply 0 retweets 0 likes -
Replying to @propensive
@propensive@xeno_by Could you elaborate on that? :-)2 replies 0 retweets 0 likes -
Replying to @viktorklang
@viktorklang@xeno_by i.e. it could be as simple as writing `val foo: Foo = alloc`, (provided Foo has a zero-arity constructor).1 reply 0 retweets 0 likes -
Replying to @propensive
@propensive@xeno_by I'd be fine with not having inference for it, it'd just be cleaner.2 replies 0 retweets 0 likes
@viktorklang @xeno_by The thing is, you lose type inference on the type parameters too, so it would often be more verbose. :(
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.