John C wrote: > Here's a couple of annoying problems I encounter quite often with D's > properties. Would having some form of property syntax fix them? > > 1) Array extensions: > > class Person { > > string name_; > > string name() { > return name_; > } > > } > > auto person = getPerson(); > auto firstAndLast = person.name.split(' '); > > The above line currently requires parentheses after 'name' to compile. >
This one is weird. After defining getPerson() I was able to rewrite the last line into this and make it compile: auto firstAndLast = split(person.name," "); Note that you need qoutes, not just ' '. But even auto firstAndLast = person.name.split(" "); does not compile. main2.d(36): Error: function expected before (), not split(person.name()) of type immutable(char)[][] This is probably a compiler bug. I don't think property syntax is truly necessary for this example. You are fortunate enough to be using strings, which are passed by reference. > 2) Indexing: > > struct Map(K, V) { > > void opIndexAssign(V value, K key) { ... } > V opIndex(K key) { ... } > > } > > class WebClient { > > private Map!(string, string) headers_; > > Map!(string, string) headers() { > return headers_; > } > > } > > auto client = new WebClient(); > client.headers["User-Agent"] = "MyWebClient"; > > The compiler says client.headers() is not an lvalue (adding 'ref' in D2 > changes nothing). This is nearly the same thing as the "a.b.c = 3;" example given in the "a.b.c = 3;" thread. The .b is your .headers. It's slightly more forgiving though, since you are calling a function on the returned struct and not accessing a field. The setter never needs to be called in your example. I'll use the compiler's rewritting technique to show you what it looks like: client.headers["User-Agent"] = "MyWebClient"; client.headers.opIndexAssign("User-Agent","MyWebClient"); client.headers().opIndexAssign("User-Agent","MyWebClient"); client.headers() creates a /new/ Map!(...) struct, so the opIndexAssign will not be called on the one you want it to be called on. Adding 'ref' should change that. That sounds like a bug. In this specific example, property syntax is not truly necessary. That ref returns were added should make this doable.