On Tuesday, 3 September 2013 at 19:10:12 UTC, Jacob Carlborg wrote:
> On 2013-09-03 21:05, Andrej Mitrovic wrote:
>
>> You are importing symbols. And when you do "foo()" you know you're
>> calling a function. With the change, you'll never know what foo()
>> does.
>>
>> This feature is never going to fly, but people are just going to argue
>> this forever..
>
> With properties you never know if you're invoking a method or accessing a field:
>
> foo.data; // call method or access field?

Which is exactly why parens-less calls and properties with side effects suck.

On 9/3/13, Jacob Carlborg <doob@me.com> wrote:
> With properties you never know if you're invoking a method or accessing a field:
>
> foo.data; // call method or access field?

Yeah but it does something with data on its own side. If this becomes an implicit mixin, it could do something with code at the call site. E.g.

auto st = getSecurityToken(...);
updateGui();  // what if this becomes a mixin and ends up reading 'st'
and displaying it on the screen?

It is equivalent to using globals everywhere in your codebase.

the other part of my post was about UFCS syntax for mixin: eg: foo.mixin.writeln

is there any reason not to allow it?



On Tue, Sep 3, 2013 at 1:47 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:

> On 9/3/13, Jacob Carlborg <doob@me.com> wrote:
> > With properties you never know if you're invoking a method or accessing a field:
> >
> > foo.data; // call method or access field?
>
> Yeah but it does something with data on its own side. If this becomes an implicit mixin, it could do something with code at the call site. E.g.
>
> auto st = getSecurityToken(...);
> updateGui();  // what if this becomes a mixin and ends up reading 'st'
> and displaying it on the screen?
>
> It is equivalent to using globals everywhere in your codebase.
>

On Tue, Sep 3, 2013 at 12:13 PM, Dicebot <public@dicebot.lv> wrote:

> On Tuesday, 3 September 2013 at 19:10:12 UTC, Jacob Carlborg wrote:
>
>> On 2013-09-03 21:05, Andrej Mitrovic wrote:
>>
>>  You are importing symbols. And when you do "foo()" you know you're
>>> calling a function. With the change, you'll never know what foo()
>>> does.
>>>
>>> This feature is never going to fly, but people are just going to argue this forever..
>>>
>>
>> With properties you never know if you're invoking a method or accessing a field:
>>
>> foo.data; // call method or access field?
>>
>
> Which is exactly why parens-less calls and properties with side effects suck.
>

that's the whole point, it allows to transparently replace a field access by a property function call without breaking client code. How else would you do that?

On Wednesday, 4 September 2013 at 02:26:27 UTC, Timothee Cour wrote:
> that's the whole point, it allows to transparently replace a field access
> by a property function call without breaking client code. How else would
> you do that?

You can't replace field access with function call transparently if it has side effects. In the end breakage may be even worse. For me only replacing @property fields with @property methods makes sense (with former prohibited to be taken address of and latter forced to be weakly pure).'

On 9/3/13 4:05 PM, Andrej Mitrovic wrote:
> On 9/3/13, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>> When you do "import foo.bar" you are importing arbitrary code...
>
> You are importing symbols. And when you do "foo()" you know you're
> calling a function. With the change, you'll never know what foo()
> does.

Yes you know: you look at the source code, or the documentation.

>
> This feature is never going to fly, but people are just going to argue
> this forever..

I know, I'm just trying to defend this point of view.

On 9/3/13 5:47 PM, Andrej Mitrovic wrote:
> On 9/3/13, Jacob Carlborg <doob@me.com> wrote:
>> With properties you never know if you're invoking a method or accessing
>> a field:
>>
>> foo.data; // call method or access field?
>
> Yeah but it does something with data on its own side. If this becomes
> an implicit mixin, it could do something with code at the call site.
> E.g.
>
> auto st = getSecurityToken(...);
> updateGui();  // what if this becomes a mixin and ends up reading 'st'
> and displaying it on the screen?
>
> It is equivalent to using globals everywhere in your codebase.

Why would anyone do that?

Do you use other people's source code without reading the documentation or reading the source code?

How would the author of "updateGui()" know that you named your variable "st"?

What if "updateGui()" does "rm -rf /" ?

What if "updateGui()" always does a null pointer dereference?

Ah, the language is too dangerous. I say we should remove function calls from the language.

On Wednesday, 4 September 2013 at 14:42:26 UTC, Ary Borenszweig wrote:
> On 9/3/13 4:05 PM, Andrej Mitrovic wrote:
>> On 9/3/13, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>>> When you do "import foo.bar" you are importing arbitrary code...
>>
>> You are importing symbols. And when you do "foo()" you know you're
>> calling a function. With the change, you'll never know what foo()
>> does.
>
> Yes you know: you look at the source code, or the documentation.

You don't do it for _every single symbol_. Good good matches naive assumptions, this is exactly what allows to read it fast. Reading code where you can't make assumptions about anything is a transitive (possibly exponential) task. Exactly the hell you get with undisciplined C macro usage.

On Wednesday, 4 September 2013 at 14:44:50 UTC, Ary Borenszweig wrote:
> Why would anyone do that?

By an accident - mixins are not hygienic.

> Do you use other people's source code without reading the documentation or reading the source code?

Yes, all the time. Documentation is always lacking and reading full 10 MLOC code base to tweak a single function is never an option.

> How would the author of "updateGui()" know that you named your variable "st"?

He has no idea how you may name your variables, that is the key point. Thus he has no idea what safe symbol names to use.

> What if "updateGui()" does "rm -rf /" ?
>
> What if "updateGui()" always does a null pointer dereference?

You will have a bugged/malicious function in your code base, one very easy to detect and fix. Nothing in common with discussed problem.

On 9/4/13 11:54 AM, Dicebot wrote:
> On Wednesday, 4 September 2013 at 14:44:50 UTC, Ary Borenszweig wrote:
>> Why would anyone do that?
>
> By an accident - mixins are not hygienic.
>
>> Do you use other people's source code without reading the
>> documentation or reading the source code?
>
> Yes, all the time. Documentation is always lacking and reading full 10
> MLOC code base to tweak a single function is never an option.
>
>> How would the author of "updateGui()" know that you named your
>> variable "st"?
>
> He has no idea how you may name your variables, that is the key point.
> Thus he has no idea what safe symbol names to use.

So the problem is not that implicit mixin is unsafe. The problem is that there's no way to declare a new variable that won't conflict with existing variables in the current scope?