On Tuesday, September 04, 2012 00:21:53 Carl Sturtivant wrote: > ---same thing (specialized to struct S) in my first reply. > I'm just fishing, seeking a boundary. > > There is a cleanness issue to discuss. It would be nice to know > what you think about implicit conversion from 'S*' to 'ref S' > (and not the other way as someone seemed to be suggesting).
Pointers and ref are two entirely different things and shouldn't be treated the same. If you want to pass the pointer to ref S, then dereference it. Any and all implicit conversions should be treated with care. D has far fewer than C/C++ specifically because they're a major source of bugs. > It's hard for a newish outsider to get a sense of where the boundaries > lie. We're trying _not_ to add new features. D is supposed to be stabilizing. The language definition is essentially frozen. We pretty much only add features when we really need to. Any and all new language features need to solve a real problem and need to carry their weight. If anything, the trend is to _remove_ features from the language and move them into the library rather than add them to the language (e.g. scope on local variables being axed in favor of std.typecons.Scoped). You need a _really_ good reason for a new language feature, or it's not going to happen. Pretty much the only feature that was added at all recently which had anything to do with syntactic niceties was UFCS, and that was extension of an existing feature with arrays, long sought-after, and depending on how you read TDPL, it implied that the feature was in the language. So, it got added. But in general, something that's trying to adjust syntax isn't going to happen, because that's a matter of aesthetics. _Always_ look to solve the problem within the language first. If you can, then it's _highly_ unlikely that your problem merits a new language feature. - Jonathan M Davis