pointers, functions, and uniform call syntax

[Carl Sturtivant]

On Monday, 3 September 2012 at 22:38:28 UTC, Jonathan M Davis 
wrote:
> 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

Thank you for your frankness. The above being the case, I wonder 
why p.frog where p is a pointer has been made to work when a 
wrapper will do the job. Is that something that might best be 
removed? It is after all an aesthetic matter.