www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - proposal: mixin functions to auto-mixin at call site

reply Timothee Cour <thelastmammoth gmail.com> writes:
--e89a8ff1cf82f91f7904e572ee10
Content-Type: text/plain; charset=ISO-8859-1

I'd like to be able to declare a function with a special  mixin property
that will auto-mixin at call site:

 mixin string foo(){return some_string;}
void main(){
 foo; //behaves as mixin(foo()); if  mixin weren't provided
}

This is purely syntax sugar, as it could be done with a mixin at call site,
but is very useful in a number of scenarios:

Example 1:
I wrote a string parsing function 'embed' that allows to embed variables in
current scope in a string:
void main(){
int x1=11;
double x2=2.3;
assert(mixin("variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed) ==
"variables: x1=11, x2=2.3, sum=13.3");
}
The 'embed' function parses the input string, extracts the '$' tokens (with
a proper escape mechanism) and return a string of the form 'std.conv.text(
...)' with appropriate arguments so that the string can be mixed in at call
site as above.

Without the  mixin property we have:
mixin("variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed)

With the proposed  mixin property this would simplify to:
"variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed

Which is simpler and easier to read than:

text("variables: x1=",x1,", x2=",x2,", sum=",x1+x2);


There are many other use cases.

If for some reason we can't have  mixin special property, can we at least
have UFCS for mixin, so that we could write:
"variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin

--e89a8ff1cf82f91f7904e572ee10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;d like to be able to declare a function with a speci=
al  mixin property that will auto-mixin at call site:<div><br><div> mixin s=
tring foo(){return some_string;}</div><div>void main(){</div><div>=A0foo; /=
/behaves as mixin(foo()); if  mixin weren&#39;t provided</div>
<div>}</div></div><div><br></div><div>This is purely syntax sugar, as it co=
uld be done with a mixin at call site, but is very useful in a number of sc=
enarios:</div><div><br></div><div>Example 1:</div><div>I wrote a string par=
sing function &#39;embed&#39; that allows to embed variables in current sco=
pe in a string:</div>
<div>void main(){</div><div>int x1=3D11;<br></div><div><div>double x2=3D2.3=
;</div></div><div>assert(mixin(&quot;variables: x1=3D$x1, x2=3D$x2, sum=3D$=
(x1+x2)&quot;.embed) =3D=3D &quot;variables: x1=3D11, x2=3D2.3, sum=3D13.3&=
quot;);<br></div>
<div>}<br></div><div>The &#39;embed&#39; function parses the input string, =
extracts the &#39;$&#39; tokens (with a proper escape mechanism) and return=
 a string of the form &#39;std.conv.text( ...)&#39; with appropriate argume=
nts so that the string can be mixed in at call site as above.</div>
<div><br></div><div>Without the  mixin property we have:</div><div>mixin(&q=
uot;variables: x1=3D$x1, x2=3D$x2, sum=3D$(x1+x2)&quot;.embed)<br></div><di=
v><br></div><div>With the proposed  mixin property this would simplify to:<=
/div>
<div>&quot;variables: x1=3D$x1, x2=3D$x2, sum=3D$(x1+x2)&quot;.embed<br></d=
iv><div><br></div><div>Which is simpler and easier to read than:</div><div>=
<br></div><div>text(&quot;variables: x1=3D&quot;,x1,&quot;, x2=3D&quot;,x2,=
&quot;, sum=3D&quot;,x1+x2);</div>
<div><br></div><div><br></div><div>There are many other use cases.=A0</div>=
<div><br></div><div>If for some reason we can&#39;t have  mixin special pro=
perty, can we at least have UFCS for mixin, so that we could write:</div>
<div><div>&quot;variables: x1=3D$x1, x2=3D$x2, sum=3D$(x1+x2)&quot;.embed.m=
ixin<br></div></div><div><br></div><div><br></div></div>

--e89a8ff1cf82f91f7904e572ee10--
Sep 02 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 3 September 2013 at 04:15:17 UTC, Timothee Cour wrote:
 I'd like to be able to declare a function with a special  mixin 
 property
 that will auto-mixin at call site

Kenji had apparently implemented this: https://github.com/D-Programming-Language/dmd/pull/459 But pulled out. This recent thread should sum it up: http://forum.dlang.org/thread/yaasjclvyobpeftgwmke forum.dlang.org Long story short, you are basically asking for macro. If we allowed this, than anything could actually be code injection, and mean anything.
 If for some reason we can't have  mixin special property, can 
 we at least
 have UFCS for mixin, so that we could write:
 "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin

I'm not sure this us very interesting (why not though), since nothing would ever come after the mixin. I'd still rather have "typeof" be UFCS-able: 5.typeof.stringof.writeln(); If we only got to choose 1 that is ;)
Sep 02 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-03 07:11, monarch_dodra wrote:

 Kenji had apparently implemented this:
 https://github.com/D-Programming-Language/dmd/pull/459

 But pulled out. This recent thread should sum it up:
 http://forum.dlang.org/thread/yaasjclvyobpeftgwmke forum.dlang.org

 Long story short, you are basically asking for macro. If we
 allowed this, than anything could actually be code injection, and
 mean anything.

Yes, this seems to be another workaround for some kind of AST macros. -- /Jacob Carlborg
Sep 03 2013
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 9/3/13 2:11 AM, monarch_dodra wrote:
 On Tuesday, 3 September 2013 at 04:15:17 UTC, Timothee Cour wrote:
 I'd like to be able to declare a function with a special  mixin property
 that will auto-mixin at call site

Kenji had apparently implemented this: https://github.com/D-Programming-Language/dmd/pull/459 But pulled out. This recent thread should sum it up: http://forum.dlang.org/thread/yaasjclvyobpeftgwmke forum.dlang.org Long story short, you are basically asking for macro. If we allowed this, than anything could actually be code injection, and mean anything.
 If for some reason we can't have  mixin special property, can we at least
 have UFCS for mixin, so that we could write:
 "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin

I'm not sure this us very interesting (why not though), since nothing would ever come after the mixin. I'd still rather have "typeof" be UFCS-able: 5.typeof.stringof.writeln(); If we only got to choose 1 that is ;)

"Today if anyone writes or sees sees mixin(stuff) they are well warned that arbitrary code generation is taking place and are ready to deal with the consequences." When you do "import foo.bar" you are importing arbitrary code... If you are not sure what that does, you go look it up. And it's the same for implicit mixins. I don't see the issue at all...
Sep 03 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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? -- /Jacob Carlborg
Sep 03 2013
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Sep 04 2013
parent Ary Borenszweig <ary esperanto.org.ar> writes:
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?
Sep 04 2013
prev sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Sep 04 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--e89a8ff1cf824ac57f04e57668ca
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 2, 2013 at 10:11 PM, monarch_dodra <monarchdodra gmail.com>wrote:

 On Tuesday, 3 September 2013 at 04:15:17 UTC, Timothee Cour wrote:

 I'd like to be able to declare a function with a special  mixin property
 that will auto-mixin at call site

Kenji had apparently implemented this: https://github.com/D-**Programming-Language/dmd/pull/**459<https://github.com/D-Programming-Language/dmd/pull/459> But pulled out. This recent thread should sum it up: http://forum.dlang.org/thread/**yaasjclvyobpeftgwmke forum.**dlang.org<http://forum.dlang.org/thread/yaasjclvyobpeftgwmke forum.dlang.org>

The last comment from Andrei in https://github.com/D-Programming-Language/dmd/pull/459 is actually rather supportive of such feature, and seemed to encourage a more thorough discussion which never happened (AFAIK). And unlike what is said in the thread above (last comment), the feature indeed was implemented already, but not merged.
 Long story short, you are basically asking for macro. If we
 allowed this, than anything could actually be code injection, and
 mean anything.

No, only mixin statements and mixin functions. And a regular function calling a mixin function would still be regular, eg not able to access symbols in enclosing scope by name. Given that properties can be queried at compile time, there is no ambiguity. Proper tooling can reveal which statements are mixins if needed (which doesn't imply that the language readability depends on having an IDE).
  If for some reason we can't have  mixin special property, can we at least
 have UFCS for mixin, so that we could write:
 "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin

I'm not sure this us very interesting (why not though), since nothing would ever come after the mixin.

What do you mean by "nothing would ever come after the mixin" ? You can have: some_string.embed.mixin.writeln; Simple use case: or: assert(foo(x)==bar(y), "error with $(foo(x)) and $(bar(y)) ".embed); I'd still rather have "typeof" be UFCS-able:
 5.typeof.stringof.writeln();

 If we only got to choose 1 that is ;)

Features should be orthogonal unless there's a good reason not to. IMO, assert, typeof, mixin, etc should all be UFCS-able. But this has been brought up many times before. --e89a8ff1cf824ac57f04e57668ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">On Mon, Sep 2, 2013 at 10:11 PM, monarch_dodra <span dir=3D"ltr">&l= t;<a href=3D"mailto:monarchdodra gmail.com" target=3D"_blank">monarchdodra = gmail.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"im">On Tuesday, 3 September 2013 at 04:15:17= UTC, Timothee Cour wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> I&#39;d like to be able to declare a function with a special mixin propert= y<br> that will auto-mixin at call site<br> </blockquote> <br></div> Kenji had apparently implemented this:<br> <a href=3D"https://github.com/D-Programming-Language/dmd/pull/459" target= =3D"_blank">https://github.com/D-<u></u>Programming-Language/dmd/pull/<u></= u>459</a><br> <br> But pulled out. This recent thread should sum it up:<br> <a href=3D"http://forum.dlang.org/thread/yaasjclvyobpeftgwmke forum.dlang.o= rg" target=3D"_blank">http://forum.dlang.org/thread/<u></u>yaasjclvyobpeftg= wmke forum.<u></u>dlang.org</a></blockquote><div><br></div><div>The last co= mment from Andrei in <a href=3D"https://github.com/D-Programming-Language/d= md/pull/459">https://github.com/D-Programming-Language/dmd/pull/459</a>=A0i= s actually rather supportive of such feature, and seemed to encourage a mor= e thorough discussion which never happened (AFAIK).</div> <div>And unlike what is said in the thread above (last comment), the featur= e indeed was implemented already, but not merged.</div><div><br></div><div>= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl= e:solid;padding-left:1ex"> Long story short, you are basically asking for macro. If we<br> allowed this, than anything could actually be code injection, and<br> mean anything.</blockquote><div><br></div><div>No, only mixin statements an= d mixin functions. And a regular function calling a mixin function would = still be regular, eg not able to access symbols in enclosing scope by name.= </div> <div>Given that properties can be queried at compile time, there is no ambi= guity. Proper tooling can reveal which statements are mixins if needed (whi= ch doesn&#39;t imply that the language readability depends on having an IDE= ).=A0</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left= -style:solid;padding-left:1ex"><div class=3D"im"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> If for some reason we can&#39;t have mixin special property, can we at lea= st<br> have UFCS for mixin, so that we could write:<br> &quot;variables: x1=3D$x1, x2=3D$x2, sum=3D$(x1+x2)&quot;.embed.mixin<br> </blockquote> <br></div> I&#39;m not sure this us very interesting (why not though), since<br> nothing would ever come after the mixin.<br></blockquote><div><br></div><di= v>What do you mean by &quot;nothing would ever come after the mixin&quot; ?= </div><div><div>You can have: some_string.embed.mixin.writeln;</div></div> <div><br></div><div>Simple use case:</div><div>or: assert(foo(x)=3D=3Dbar(y= ), &quot;error with $(foo(x)) and=A0$(bar(y)) &quot;.embed);<br></div><div>= <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty= le:solid;padding-left:1ex"> I&#39;d still rather have &quot;typeof&quot; be UFCS-able:<br> 5.typeof.stringof.writeln();<br> <br> If we only got to choose 1 that is ;)<br></blockquote><div><br></div><div>F= eatures should be orthogonal unless there&#39;s a good reason not to. IMO, = assert, typeof, mixin, etc should all be UFCS-able. But this has been broug= ht up many times before.</div> <div><br></div></div></div></div> --e89a8ff1cf824ac57f04e57668ca--
Sep 03 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 3 September 2013 at 08:23:57 UTC, Timothee Cour wrote:
 Long story short, you are basically asking for macro. If we
 allowed this, than anything could actually be code injection, 
 and
 mean anything.

No, only mixin statements and mixin functions. And a regular function calling a mixin function would still be regular, eg not able to access symbols in enclosing scope by name.

But that sill implies knowing exactly *what* is called, eg knowing the documentation of everything that is used, as opposed to just knowing "that *looks* like a function call that *does* something or other", but not worrying about it more than that. Allowing implicit mixin adds an entire extra level of "dereference" when reading wode.
  If for some reason we can't have  mixin special property, can 
 we at least
 have UFCS for mixin, so that we could write:
 "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin

I'm not sure this us very interesting (why not though), since nothing would ever come after the mixin.

What do you mean by "nothing would ever come after the mixin" ? You can have: some_string.embed.mixin.writeln;

Hadn't thought of that.
Sep 03 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
Was objecting in previous thread and have not changed my mind - 
it is unhygienic and mostly useless.
Sep 03 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 3 September 2013 at 18:26:57 UTC, Ary Borenszweig 
wrote:
 On 9/3/13 2:11 AM, monarch_dodra wrote:
 On Tuesday, 3 September 2013 at 04:15:17 UTC, Timothee Cour 
 wrote:
 I'd like to be able to declare a function with a special 
  mixin property
 that will auto-mixin at call site

Kenji had apparently implemented this: https://github.com/D-Programming-Language/dmd/pull/459 But pulled out. This recent thread should sum it up: http://forum.dlang.org/thread/yaasjclvyobpeftgwmke forum.dlang.org Long story short, you are basically asking for macro. If we allowed this, than anything could actually be code injection, and mean anything.
 If for some reason we can't have  mixin special property, can 
 we at least
 have UFCS for mixin, so that we could write:
 "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin

I'm not sure this us very interesting (why not though), since nothing would ever come after the mixin. I'd still rather have "typeof" be UFCS-able: 5.typeof.stringof.writeln(); If we only got to choose 1 that is ;)

"Today if anyone writes or sees sees mixin(stuff) they are well warned that arbitrary code generation is taking place and are ready to deal with the consequences." When you do "import foo.bar" you are importing arbitrary code... If you are not sure what that does, you go look it up. And it's the same for implicit mixins. I don't see the issue at all...

But "import" is also explicit. Do you think it would be a good idea that a function be allowed to implicitly import things just by calling it? Because that basically what implicit mixin allows.
Sep 03 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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. This feature is never going to fly, but people are just going to argue this forever..
Sep 03 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Sep 03 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Sep 03 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--089e01634b1ed3895f04e5815c4b
Content-Type: text/plain; charset=ISO-8859-1

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.

--089e01634b1ed3895f04e5815c4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">the other part of my post was about UFCS syntax for mixin:= <div>eg: foo.mixin.writeln</div><div><br></div><div>is there any reason not= to allow it?</div><div><br></div></div><div class=3D"gmail_extra"><br><br>= <div class=3D"gmail_quote"> On Tue, Sep 3, 2013 at 1:47 PM, Andrej Mitrovic <span dir=3D"ltr">&lt;<a hr= ef=3D"mailto:andrej.mitrovich gmail.com" target=3D"_blank">andrej.mitrovich= gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 9/3/13, Jacob Carlborg &lt;<a href=3D"mailto:doob me.c= om">doob me.com</a>&gt; wrote:<br> &gt; With properties you never know if you&#39;re invoking a method or acce= ssing<br> &gt; a field:<br> &gt;<br> &gt; foo.data; // call method or access field?<br> <br> </div>Yeah but it does something with data on its own side. If this becomes= <br> an implicit mixin, it could do something with code at the call site.<br> E.g.<br> <br> auto st =3D getSecurityToken(...);<br> updateGui(); =A0// what if this becomes a mixin and ends up reading &#39;st= &#39;<br> and displaying it on the screen?<br> <br> It is equivalent to using globals everywhere in your codebase.<br> </blockquote></div><br></div> --089e01634b1ed3895f04e5815c4b--
Sep 03 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--001a11c2e74c8b06e604e58587ad
Content-Type: text/plain; charset=ISO-8859-1

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? --001a11c2e74c8b06e604e58587ad Content-Type: text/html; charset=ISO-8859-1 <div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 3, 2013 at 12:13 PM, Dicebot <span dir="ltr">&lt;<a href="mailto:public dicebot.lv" target="_blank">public dicebot.lv</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tuesday, 3 September 2013 at 19:10:12 UTC, Jacob Carlborg wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 2013-09-03 21:05, Andrej Mitrovic wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> You are importing symbols. And when you do &quot;foo()&quot; you know you&#39;re<br> calling a function. With the change, you&#39;ll never know what foo()<br> does.<br> <br> This feature is never going to fly, but people are just going to argue<br> this forever..<br> </blockquote> <br> With properties you never know if you&#39;re invoking a method or accessing a field:<br> <br> foo.data; // call method or access field?<br> </blockquote> <br></div></div> Which is exactly why parens-less calls and properties with side effects suck.<br> </blockquote></div><br></div><div class="gmail_extra">that&#39;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?</div> <div class="gmail_extra"><br></div></div> --001a11c2e74c8b06e604e58587ad--
Sep 03 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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).'
Sep 04 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Sep 04 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Sep 04 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 4 September 2013 at 15:18:10 UTC, Ary Borenszweig 
wrote:
 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?

This is the same problem. The key property of mixin is that it is unhygienic and invades the caller scope. It is the only entity in D that is allowed to do it. Allowing implicit unhygienic inclusions is guaranteed to result in accidental symbol clash and/or unexpected modification sooner or later.
Sep 04 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--001a11c1caee8fa18504e591d616
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 4, 2013 at 2:23 AM, Dicebot <public dicebot.lv> wrote:

 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).'

IIRC, &foo.x with x a property should take address of return value of x(), which will either fail to compile or do the right thing if it returns a lvalue. So there's no undefined behavior as far as taking address of is concerned when replacing field by property. As for side effects, this is the reason one would go from field access to property, eg populating some data upon 1st access to a field x. Sure it can be misused, but I haven't seen a case in practice where it is misused. --001a11c1caee8fa18504e591d616 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W= ed, Sep 4, 2013 at 2:23 AM, Dicebot <span dir=3D"ltr">&lt;<a href=3D"mailto= :public dicebot.lv" target=3D"_blank">public dicebot.lv</a>&gt;</span> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s= olid;padding-left:1ex"> <div class=3D"im">On Wednesday, 4 September 2013 at 02:26:27 UTC, Timothee = Cour wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> that&#39;s the whole point, it allows to transparently replace a field acce= ss<br> by a property function call without breaking client code. How else would<br=

</blockquote> <br></div> You can&#39;t replace field access with function call transparently if it h= as side effects. In the end breakage may be even worse. For me only replaci= ng property fields with property methods makes sense (with former prohibi= ted to be taken address of and latter forced to be weakly pure).&#39;<br> </blockquote><div><br></div>IIRC, &amp;foo.x with x a property should take = address of return value of x(), which will either fail to compile or do the= right thing if it returns a lvalue. So there&#39;s no undefined behavior a= s far as taking address of is concerned when replacing field by property.= =A0</div> <div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">As for side= effects, this is the reason one would go from field access to property, eg= populating some data upon 1st access to a field x. Sure it can be misused,= but I haven&#39;t seen a case in practice where it is misused.<br> <div class=3D"gmail_extra"><br><br></div><div>=A0</div></div><br></div></di= v> --001a11c1caee8fa18504e591d616--
Sep 04 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--089e01634b1e50d86b04e591e143
Content-Type: text/plain; charset=ISO-8859-1

frankly, UFCS mixin would make the use case in the OT bearable.

fun().mixin.writeln is ok
mixin(fun()).writeln is ugly (esp in more complex cases).

so, is there anything against it despite requiring one to implement it?


On Wed, Sep 4, 2013 at 8:29 AM, Dicebot <public dicebot.lv> wrote:

 On Wednesday, 4 September 2013 at 15:18:10 UTC, Ary Borenszweig wrote:

 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?

This is the same problem. The key property of mixin is that it is unhygienic and invades the caller scope. It is the only entity in D that is allowed to do it. Allowing implicit unhygienic inclusions is guaranteed to result in accidental symbol clash and/or unexpected modification sooner or later.

--089e01634b1e50d86b04e591e143 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">frankly, UFCS mixin would make the use case in the OT bear= able.<div><br></div><div>fun().mixin.writeln is ok</div><div>mixin(fun()).w= riteln is ugly (esp in more complex cases).</div><div><br></div><div>so, is= there anything against it despite requiring one to implement it?</div> </div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,= Sep 4, 2013 at 8:29 AM, Dicebot <span dir=3D"ltr">&lt;<a href=3D"mailto:pu= blic dicebot.lv" target=3D"_blank">public dicebot.lv</a>&gt;</span> wrote:<= br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Wednesday, 4 September 2013 at 15:18:10 UTC, Ary Boren= szweig wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> So the problem is not that implicit mixin is unsafe. The problem is that th= ere&#39;s no way to declare a new variable that won&#39;t conflict with exi= sting variables in the current scope?<br> </blockquote> <br></div> This is the same problem. The key property of mixin is that it is unhygieni= c and invades the caller scope. It is the only entity in D that is allowed = to do it. Allowing implicit unhygienic inclusions is guaranteed to result i= n accidental symbol clash and/or unexpected modification sooner or later.<b= r> </blockquote></div><br></div> --089e01634b1e50d86b04e591e143--
Sep 04 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 4 September 2013 at 17:07:33 UTC, Timothee Cour 
wrote:
 IIRC, &foo.x with x a property should take address of return 
 value of x(),
 which will either fail to compile or do the right thing if it 
 returns a
 lvalue.

It is not possible because getters are not guaranteed to return lvalues. There is a quite elegant (in my opinion) proposal hanging around to allow annotating plain fields with property so that compiler will prohibit doing any operation on them that may later break because of transition to actual properties, such as taking address.
 As for side effects, this is the reason one would go from field 
 access to
 property, eg populating some data upon 1st access to a field x. 
 Sure it can
 be misused, but I haven't seen a case in practice where it is 
 misused.

I haven't seen a case in practice when using normal method instead of a property was really harmful. Also modifying own members is legal for weakly pure method as far as I remember (it can modify arguments, including hidden `this`), so your case will actually work within my restrictions.
Sep 05 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 4 September 2013 at 17:10:32 UTC, Timothee Cour 
wrote:
 frankly, UFCS mixin would make the use case in the OT bearable.

 fun().mixin.writeln is ok
 mixin(fun()).writeln is ugly (esp in more complex cases).

 so, is there anything against it despite requiring one to 
 implement it?

I guess there is nothing terrible but also nothing extremely useful :) For me second snippet is not any uglier.
Sep 05 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 September 2013 at 10:36:40 UTC, Dicebot wrote:
 On Wednesday, 4 September 2013 at 17:10:32 UTC, Timothee Cour 
 wrote:
 frankly, UFCS mixin would make the use case in the OT bearable.

 fun().mixin.writeln is ok
 mixin(fun()).writeln is ugly (esp in more complex cases).

 so, is there anything against it despite requiring one to 
 implement it?

I guess there is nothing terrible but also nothing extremely useful :) For me second snippet is not any uglier.

Stuff like data validation, or lazy initialization, anything really data oriented usually benefit from that. Also, the dichotomy function call/field access is really not that clear at the end. Accessing some data may require a function call, go through a signal handler, or involve complicated operation by the CPU (potentially 2 round trip to memory). On the other hand, optimizer will remove many function calls making them effectively field access. Even if it isn't inlined, a simple function call could end up being faster than 2 round trip to memory (the stack is hot).
Sep 05 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 5 September 2013 at 10:51:19 UTC, deadalnix wrote:
 Stuff like data validation, or lazy initialization, anything 
 really data oriented usually benefit from that.

 Also, the dichotomy function call/field access is really not 
 that clear at the end. Accessing some data may require a 
 function call, go through a signal handler, or involve 
 complicated operation by the CPU (potentially 2 round trip to 
 memory).

 On the other hand, optimizer will remove many function calls 
 making them effectively field access. Even if it isn't inlined, 
 a simple function call could end up being faster than 2 round 
 trip to memory (the stack is hot).

I guess it was an answer to earlier property comment. Key concern here is not actually speed but ease to understand the program - it is pretty much the same deal as pure vs non-pure. Non-volatile non-shared field access is extremely unlikely to cause any side-effects in global program state and same is generally expected from something that looks like plain field access.
Sep 05 2013