On Monday, 20 May 2013 at 19:26:28 UTC, Maxim Fomin wrote:
And this is pushing UFCS beyond its purpose for the sake of
temporal convenience at the expense of language.
I suspect you're correct on this. The only reason I suggested
using UFCS was that it could be a library solution as opposed
On 05/21/2013 08:24 PM, Maxim Fomin wrote:
...
According to the spec (overload page and TDPL) operators are rewritten
specifically named *member* functions and calling *member* function is
not the same thing as syntax to call free functions like member
functions due to:
- non-member (UFCS)
On Tue, 21 May 2013 15:36:31 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 05/21/2013 05:31 PM, Steven Schveighoffer wrote:
On Mon, 20 May 2013 11:15:32 -0400, John Colvin
john.loughran.col...@gmail.com wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
On 05/21/2013 09:53 PM, Steven Schveighoffer wrote:
On Tue, 21 May 2013 15:36:31 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 05/21/2013 05:31 PM, Steven Schveighoffer wrote:
...
This handles your case using opDispatch:
import std.stdio,std.conv,std.algorithm,std.array;
string
On Tue, 21 May 2013 16:16:08 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 05/21/2013 09:53 PM, Steven Schveighoffer wrote:
At the end of the day, it's going to be less boilerplate for the
std.typecons.Proxy that one has to mixin. User code will look the same.
...
For user code there is a
On Tuesday, 21 May 2013 at 10:53:04 UTC, Timon Gehr wrote:
On 05/21/2013 10:40 AM, Maxim Fomin wrote:
On Monday, 20 May 2013 at 23:10:48 UTC, Timon Gehr wrote:
...
In some notorious cases such artificiality created
problems (for local convenience at the expense of language
consistency)
I
On 05/21/2013 05:31 PM, Steven Schveighoffer wrote:
On Mon, 20 May 2013 11:15:32 -0400, John Colvin
john.loughran.col...@gmail.com wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S'
On Monday, 20 May 2013 at 23:10:48 UTC, Timon Gehr wrote:
On 05/20/2013 10:08 PM, Maxim Fomin wrote:
I refer to more complex cases where fear introduction of
subtle bugs
caused by combination of buggy implementation and unintended
consequences which would be revealed as unexpected behavior
On 05/21/2013 10:40 AM, Maxim Fomin wrote:
On Monday, 20 May 2013 at 23:10:48 UTC, Timon Gehr wrote:
...
In some notorious cases such artificiality created
problems (for local convenience at the expense of language consistency)
I don't see how this is relevant. The compiler behaviour is at
On Monday, 20 May 2013 at 19:26:28 UTC, Maxim Fomin wrote:
On Monday, 20 May 2013 at 15:15:33 UTC, John Colvin wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and
'A'
}
On Mon, 20 May 2013 11:15:32 -0400, John Colvin
john.loughran.col...@gmail.com wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}
It would be really nice
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}
It would be really nice if opDispatch could catch missing
operator overloads.
Also, would it be a good idea to
On Monday, May 20, 2013 17:15:32 John Colvin wrote:
Also, would it be a good idea to have free functions of all the
operators (opOpAssign etc...) for builtin types somewhere? It's
occasionally useful in generic wrappers.
Why would this be useful? I think that it's just begging for trouble to
On 05/20/2013 07:19 PM, Jonathan M Davis wrote:
On Monday, May 20, 2013 17:15:32 John Colvin wrote:
Also, would it be a good idea to have free functions of all the
operators (opOpAssign etc...) for builtin types somewhere? It's
occasionally useful in generic wrappers.
Why would this be
On 05/20/2013 05:15 PM, John Colvin wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}
It would be really nice if opDispatch could catch missing operator
overloads.
On Monday, 20 May 2013 at 15:15:33 UTC, John Colvin wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}
It would be really nice if opDispatch could catch
On 05/20/2013 09:26 PM, Maxim Fomin wrote:
On Monday, 20 May 2013 at 15:15:33 UTC, John Colvin wrote:
struct S {
auto opDispatch(string s)(A i){}
}
struct A {}
void main() {
S s;
A a;
s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
}
It would be really nice if
On Monday, 20 May 2013 at 19:48:48 UTC, Timon Gehr wrote:
On 05/20/2013 09:26 PM, Maxim Fomin wrote:
This would also leads to bugs when invalid code is silently
accepted in
each user-defined type where opDispatch is defined.
This statement is wrong. As a counterexample, consider the
On 05/20/2013 10:08 PM, Maxim Fomin wrote:
On Monday, 20 May 2013 at 19:48:48 UTC, Timon Gehr wrote:
On 05/20/2013 09:26 PM, Maxim Fomin wrote:
This would also leads to bugs when invalid code is silently accepted in
each user-defined type where opDispatch is defined.
This statement is
19 matches
Mail list logo
