@property needed or not needed?

[Artur Skawina]

On 12/03/12 05:10, Timon Gehr wrote:
> On 12/02/2012 12:36 PM, Artur Skawina wrote:
>> On 12/02/12 07:57, Jonathan M Davis wrote:
>>> On Sunday, December 02, 2012 07:49:52 deadalnix wrote:
>>>> And what do you think about map!(x => x * x) = generator(x, y, z)
>>>> ?
>>>
>>> What's that even supposed to mean? map has been given no function argument
>>> either as UFCS or with a normal function call, so it's not being called. And
>>> even if it were, it wouldn't result in an lvalue, so putting it on the left of
>>> an assignment makes no sense. I have no idea what you're trying to do here.
>>
>>     void main() {
>>        import std.stdio;
>>
>>        writeln!string = "Hello World!";
>>     }
>>
>>     // The explicit "!string" is only needed because of no IFTI, if 'writeln' was
>>     // a function instead of a template you could just call it like "writeln = "blah".
>>
>> Allowing that /by default/ does much more harm than good,
> 
> It does neither harm nor good.

As long as nobody is (ab)using it.

   int f(int a) { return sqrt = a; }

is not much different from abusing op overloading and is an equally bad idea.
It shouldn't be allowed by /default/, which not enforcing @property will lead to.
Somebody reading that 'f()' definition should be able to rely on sqrt being a
variable, possibly of a user defined type, even with an overloaded assignment
operator, which could have side effects. Assuming that the type designer made
sensible choices is relatively safe, assuming that every user will do the right
thing won't work.
What would be the rationale for allowing this syntax for calling every random
function? Other than not having to declare it as a @property when required.

>> proper property enforcement is necessary. Function calls go via '()'. Programmer can override
>> when he knows better.
> 
> The first and last sentence are in mutual contradiction.

No, they are not, because enforcement is a requirement for control. And
that has to be with the producer, not the consumer (ie determined by the
function declaration, not individually at every call site).


>> [1] If you think the required '()' in UFCS chains look ugly, you're right, but the
>> right fix isn't to butcher the language. '()' carry important information.
> 
> They do not, otherwise compilation could not succeed.

not required != unimportant.

The compiler could for example in many cases figure out by itself that a missing 
(const) cast is necessary for some code to compile. That does not mean that it
should insert them implicitly, w/o making sure doing so is both harmless and
won't cause confusion.

>> Having a mode where function calls are made w/o the parens would be a good idea, but it
>> should be limited to an explicit scope. ie something like
>> "auto r = function {generator(x, y, z).map!(x => x * x)};", except 'function' keyword
>> can't be overloaded like that, it's too long, and ()-less calls isn't the only change
>> that could be done.
>>
> 
> That is terrible.

Yes, it *is* terrible - the point was that it can be done differently and this could
be a start for discussion. That kind of semi-dsl also allows for locally lifting other
restrictions like order of evaluation etc w/o butchering the rest of the language. 

artur