On Friday, 12 May 2017 at 12:56:50 UTC, drug wrote:
12.05.2017 14:58, k-five пишет:
On Friday, 12 May 2017 at 11:41:57 UTC, cym13 wrote:
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
---
also .each!writeln should be possible
12.05.2017 14:58, k-five пишет:
On Friday, 12 May 2017 at 11:41:57 UTC, cym13 wrote:
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
---
Shorter:
void main( string[] args ){
dirEntries( ".", SpanMode.depth, false )
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
I was waiting for a stable version of C++17 ( standard library
) to add some features of fileSystem in C++17 to my program
that wants to iterate through all files in a directory
recursively.
I was thinking how could I do for implementing
On Friday, 12 May 2017 at 11:58:23 UTC, k-five wrote:
On Friday, 12 May 2017 at 11:41:57 UTC, cym13 wrote:
[...]
---
[...]
-
Thanks and the correct syntax for each! is, passing a
On Friday, 12 May 2017 at 11:41:57 UTC, cym13 wrote:
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
---
Shorter:
void main( string[] args ){
dirEntries( ".", SpanMode.depth, false )
.filter!( file =>
On Friday, 12 May 2017 at 11:10:01 UTC, k-five wrote:
I was waiting for a stable version of C++17 ( standard library
) to add some features of fileSystem in C++17 to my program
that wants to iterate through all files in a directory
recursively.
I was thinking how could I do for implementing
I was waiting for a stable version of C++17 ( standard library )
to add some features of fileSystem in C++17 to my program that
wants to iterate through all files in a directory recursively.
I was thinking how could I do for implementing that and add it to
my program.
Now after starting to
:
[...]
Submit a bug report then.
I will if it turns out the behaviour is wrong, that's what
I'm checking at this stage. =)
Apologies for the extra post - does the alias function count
as declared in the same scope as the content of the function?
That would be plausible as UFCS refuses to work
the behaviour is wrong, that's what I'm
checking at this stage. =)
Apologies for the extra post - does the alias function count as
declared in the same scope as the content of the function? That
would be plausible as UFCS refuses to work on functions
declared in the same scope. Is this something
' for type 'int[]' (or whatever type I
use).
The alias rules for functions seem to be incompatible with
UFCS, F(n) works fine. What are the rewrite steps here? Is
this necessary or an oversight? Not very uniform function
call syntax.
Submit a bug report then.
I will if it turns out the behaviour
for functions seem to be incompatible with
UFCS, F(n) works fine. What are the rewrite steps here? Is
this necessary or an oversight? Not very uniform function call
syntax.
Submit a bug report then.
I will if it turns out the behaviour is wrong, that's what I'm
checking at this stage. =)
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for type 'int[]' (or whatever type I
use).
I believe UFCS is supposed to only work with top-level functions.
I don't
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for type 'int[]' (or whatever type I
use).
The alias rules for functions seem to be incompatible with
UFCS, F(n
arr, string[string] keyPredicate)
{
...filter!
}
This way I can use UFCS.
Kind regards
André
On 9/7/16 4:26 AM, Andre Pany wrote:
On Wednesday, 7 September 2016 at 08:08:34 UTC, rikki cattermole wrote:
On 07/09/2016 8:06 PM, Andre Pany wrote:
Should I open an enhancement request?
No.
It works outside of the function (part of lookup rules).
I simplified my example too much. Yes in
On Wednesday, 7 September 2016 at 08:35:26 UTC, rikki cattermole
wrote:
On 07/09/2016 8:26 PM, Andre Pany wrote:
[...]
People have tried, this is the behavior as designed.
The workaround is simple, don't use UFCS.
I won't repeat the explanation or reasoning here, plenty of
posts
ior as designed.
The workaround is simple, don't use UFCS.
I won't repeat the explanation or reasoning here, plenty of posts on it ;)
On Wednesday, 7 September 2016 at 08:08:34 UTC, rikki cattermole
wrote:
On 07/09/2016 8:06 PM, Andre Pany wrote:
Should I open an enhancement request?
No.
It works outside of the function (part of lookup rules).
I simplified my example too much. Yes in the example above I can
move the
On 07/09/2016 8:06 PM, Andre Pany wrote:
Should I open an enhancement request?
No.
It works outside of the function (part of lookup rules).
Hi,
I just noticed ufcs does not work with alias. Is this limitation
needed?
void foo(int a) {}
void main()
{
alias bar = foo;
3.foo();
3.bar();
}
Last line fails with "no property 'bar' for type int.
Should I open an enhancement request?
Kind regards
André
On Tuesday, 9 August 2016 at 05:33:09 UTC, Jonathan M Davis wrote:
Personally, I think that you should just make it a member
function if it's not a generic function, but to each their own,
Well, I use generics for when I have like, optional functionality
that isn't inherent to the class
On Tuesday, August 09, 2016 05:13:44 cy via Digitalmars-d-learn wrote:
> I really like UFCS, which is to say, defining functions outside
> the class/struct to operate on it, but you can still say
> object.function(...) and it'll get rewritten into
> function(object,...).
>
>
I really like UFCS, which is to say, defining functions outside
the class/struct to operate on it, but you can still say
object.function(...) and it'll get rewritten into
function(object,...).
Only sticky point is the convenience of "this". Like I can go
struct A {
On Tuesday, May 31, 2016 14:11:58 ixid via Digitalmars-d-learn wrote:
> On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
> > And the fact that allowing free functions to overload operators
> > via UFCS sends us into that territory just highlights the fact
> > th
On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
And the fact that allowing free functions to overload operators
via UFCS sends us into that territory just highlights the fact
that they're a horrible idea.
- Jonathan M Davis
Do you have any examples of UFCS doing bad things
Here's one more vote for extending UFCS to operator overloading.
Elie wrote that it's "a restriction that seems pointless and
arbitrary"... which summarizes my own thoughts rather well, too.
There are certainly concerning scenarios that can arise from
making this change, but the c
g. And the fact that
allowing free functions to overload operators via UFCS sends us
into that territory just highlights the fact that they're a
horrible idea.
I'd say the fact that it doesn't work, and can't currently work
for the reasons you described, points to an inconsistency in the
langu
the built-in
types. They don't need operator overloading. They already have the
operators. Operators are supposed to be used as operators, not functions,
and if there's any need to use them as functions, then there's something
seriously wrong. And the fact that allowing free functions to overload
operato
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
The difference is that it's impossible to do
10.opBinary!"+"(15), so if you're forced to do
foo.opBinary!"+"(bar) to get around a symbol conflict, it won't
work with built-in types.
Well, that begs the question: Why don't
On 25.05.2016 01:19, Elie Morisse wrote:
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
Afaik free-function operator overloads (but not in the context of
UFCS) were considered and turned down because D did not want to get
amidst discussions about adding Koenig lookup. UFCS does
te on a variety of types - including both built-in types and
user-defined types. If code is going to use +, then + must work.
opBinary!"+" is simply not going to cut it. With UFCS, if there's a
potential symbol conflict, then you can work around it - even in generic
code. But with an overloade
r overloading should be limited to class and
struct types, so that's not really relevant.
UFCS does not have that problem, because you're dealing with
free functions and can choose to not use UFCS and provide the
full import path or to alias the function, which you can't do
with operators
rced to do foo.opBinary!"+"(bar) to get around a symbol conflict,
it won't work with built-in types. UFCS does not have that problem, because
you're dealing with free functions and can choose to not use UFCS and
provide the full import path or to alias the function, which you can'
On Wednesday, 25 May 2016 at 21:50:06 UTC, Jonathan M Davis wrote:
It's not an overloaded operator anymore at that point, and that
definitely fails to work for generic code, since not all
operators are overloaded operators. Free functions don't have
that problem.
Sorry to reiterate the
er 2012 at 22:58:56 UTC, Timon Gehr wrote:
> >> > Afaik free-function operator overloads (but not in the
> >> > context of UFCS) were considered and turned down because D
> >> > did not want to get amidst discussions about adding Koenig
> >> > lookup
On Tuesday, 24 May 2016 at 23:43:46 UTC, Jonathan M Davis wrote:
On Tuesday, May 24, 2016 23:19:32 Elie Morisse via
Digitalmars-d-learn wrote:
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
> Afaik free-function operator overloads (but not in the
> context of UFCS
On Tuesday, May 24, 2016 23:19:32 Elie Morisse via Digitalmars-d-learn wrote:
> On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
> > Afaik free-function operator overloads (but not in the context
> > of UFCS) were considered and turned down because D did not want
&g
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
Afaik free-function operator overloads (but not in the context
of UFCS) were considered and turned down because D did not want
to get amidst discussions about adding Koenig lookup. UFCS does
not do Koenig lookup.
I don't get
will always be preferred over UFCS,
just like any other member access, so if you have an
unrestricted opDispatch, you basically disable ufcs on the type.
I think I was hoping that the opDispatch wouldn't compile in the
second case and it would therefore fail-over to UFCS.
std.typecons.Proxy
On Wednesday, 11 May 2016 at 23:46:48 UTC, John Colvin wrote:
Bug? Or am I misunderstanding how these two features are
supposed to interact?
I'm not sure what you actually expected there, but I'd note that
in general, opDispatch will always be preferred over UFCS, just
like any other member
struct S
{
int a;
template opDispatch(string s)
{
template opDispatch(T...)
{
auto ref opDispatch(Args ...)(auto ref Args args)
{
return S(mixin(`a.` ~ s ~ (T.length ? `!T` : ``)
~ `(args)`));
}
}
}
}
On Thursday, 31 March 2016 at 13:48:27 UTC, Adam D. Ruppe wrote:
It is trying to look up a name i in global scope, and calling
writeln on it.
This is why the .name syntax exists: so you can bypass local
variables with the same name when trying to access a global.
It would compile if you put
On Thursday, 31 March 2016 at 13:39:25 UTC, ixid wrote:
What is going on with UFCS and foreach?
foreach(i;0..5).writeln;
This is not UFCS; it is calling writeln on module scope. See
http://dlang.org/spec/module.html#module_scope_operators
Your code is semantically identical with
foreach
On Thursday, 31 March 2016 at 13:39:25 UTC, ixid wrote:
What is going on with UFCS and foreach?
There's no such thing as UFCS on foreach. UFCS only works on
variables, not a foreach statement.
foreach(i;0..5).writeln;
You can add a line break and optional braces there to see what
On Thursday, 31 March 2016 at 13:39:25 UTC, ixid wrote:
What is going on with UFCS and foreach?
foreach(i;0..5).writeln;
This prints five line breaks.
foreach(i;0..5).i.writeln;
This will not compile.
foreach(i;0..5).writeln(i);
This writes out 1 to 4 on separate lines. Is this supposed
What is going on with UFCS and foreach?
foreach(i;0..5).writeln;
This prints five line breaks.
foreach(i;0..5).i.writeln;
This will not compile.
foreach(i;0..5).writeln(i);
This writes out 1 to 4 on separate lines. Is this supposed to
work? I thought a.b would be rewritten to b
I have been working with some C error codes that are organized in
an enum. I noticed that if I tried to write a function that
processes these error codes within a struct, then I could not use
a UFCS-style call.
For instance, in the code below, I could use Baz but not Caz. It
seems to work
On Tuesday, 9 February 2016 at 21:05:50 UTC, jmh530 wrote:
For instance, in the code below, I could use Baz but not Caz.
It seems to work when I use the alternate version of Caz
calling a non-member function.
Bug?
No bug; works as intended. UFCS can only be used with free
functions
On Saturday, 9 January 2016 at 15:50:33 UTC, Jay Norwood wrote:
I'm reading Jack Stouffer's documentation:
http://jackstouffer.com/blog/nd_slice.html
considering the UFCS example below and how it would impact
auto-completion support.
auto slice = sliced(iota(1000), 5, 5, 40);
auto slice
On Saturday, 9 January 2016 at 16:00:51 UTC, cym13 wrote:
I may be very naive but how is the second form more complicated
than the first?
Pretending these were regular function implementations ...
1000.
1000.iota.
1000.iota.sliced(
iota(
sliced(
sliced(iota(
I wouldn't be surprised if
I'm reading Jack Stouffer's documentation:
http://jackstouffer.com/blog/nd_slice.html
considering the UFCS example below and how it would impact
auto-completion support.
auto slice = sliced(iota(1000), 5, 5, 40);
auto slice = 1000.iota.sliced(5, 5, 40);
Seems like auto-complete support
Bar(T) { T x; }
auto val(T)(Bar!T bar) { return bar.x; }
auto val(T)(ref Bar!T bar, float val) { return bar.x = val; }
unittest {
auto b = Bar!int();
b.val = 5;
assert(b.val == 5);
}
---
Is there a way to invoke a templated function using the UFCS
assignment syntax?
That is, can `obj.fun
On Friday, 1 January 2016 at 11:59:39 UTC, rcorre wrote:
auto val(T)(ref Bar!T bar, float val) { return bar.x = val; }
Uh, never mind. That `float` should have been `T`. Seems to work
now.
On Monday, 3 August 2015 at 22:42:15 UTC, SirNickolas wrote:
Hello! I'm new in D and it is amazing!
Can you tell me please if it is discouraged or deprecated to
call a function by just putting its name, without brackets?
It's quite unusual for me (used C++ and Python before), but I
can see
On Monday, 3 August 2015 at 22:42:15 UTC, SirNickolas wrote:
Hello! I'm new in D and it is amazing!
Can you tell me please if it is discouraged or deprecated to
call a function by just putting its name, without brackets?
It's quite unusual for me (used C++ and Python before), but I
can see
On Mon, 03 Aug 2015 22:42:14 +, SirNickolas wrote:
Hello! I'm new in D and it is amazing!
Can you tell me please if it is discouraged or deprecated to call a
function by just putting its name, without brackets? It's quite unusual
for me (used C++ and Python before), but I can see this
Hello! I'm new in D and it is amazing!
Can you tell me please if it is discouraged or deprecated to call
a function by just putting its name, without brackets? It's quite
unusual for me (used C++ and Python before), but I can see this
practice even in the official Phobos documentation:
```
On Monday, 3 August 2015 at 22:42:15 UTC, SirNickolas wrote:
Hello! I'm new in D and it is amazing!
Can you tell me please if it is discouraged or deprecated to
call a function by just putting its name, without brackets?
It's quite unusual for me (used C++ and Python before), but I
can see
You can use @property there, but you don't have to because you
can call it with optional parenthesis anyway.
On Sunday, 14 June 2015 at 12:36:43 UTC, Adam D. Ruppe wrote:
You can use @property there, but you don't have to because you
can call it with optional parenthesis anyway.
Thanks.
Is there a good reference for the current state of @property?
I know it was hotly debated for awhile (and maybe
Suppose I have a function defined like so:
void foo(int i) { }
intended to be called like:
5.foo
Should it be labeled with @property?
Or is @property only for true member functions?
On Sunday, 14 June 2015 at 12:53:43 UTC, rcorre wrote:
Is there a good reference for the current state of @property?
Easy: it does absolutely nothing right now.
I'm just never sure when I should be using it (if at all).
You should really only use it when you know the function is
On Sunday, 14 June 2015 at 12:53:43 UTC, rcorre wrote:
Is there a good reference for the current state of @property?
I know it was hotly debated for awhile (and maybe still is?).
I'm just never sure when I should be using it (if at all).
Oh yes:
On Sun, 14 Jun 2015 12:26:52 +, rcorre wrote:
Suppose I have a function defined like so:
void foo(int i) { }
intended to be called like:
5.foo
Should it be labeled with @property?
Or is @property only for true member functions?
only if you plan to use it like `foo = 5;`. i.e.
(){
S s;
s.dg=(){ writeln(!); };
s.dg();
}
Now show me the UFCS way.
i'm afraid i didn't understood you here.
compiler will not complain, but putting `@property` here is
stylistically wrong.
It's neither wrong nor right.
yet i never saw this:
struct S { int n; }
S s; s.n
to use it like `foo = 5;`.
You can use it like that anyway.
i.e. exactly like field variable.
struct S{
void delegate() dg;
}
int main(){
S s;
s.dg=(){ writeln(!); };
s.dg();
}
Now show me the UFCS way.
compiler will not complain, but putting `@property` here
Jonathan M Davis wrote:
UFCS is only ever used with the . syntax
The docs say so. Thx.
-manfred
On Saturday, 16 May 2015 at 05:56:26 UTC, Jonathan M Davis wrote:
On Friday, May 15, 2015 21:31:35 Manfred Nowak via
Digitalmars-d-learn wrote:
The following gives:
Error: 'a += b' is not a scalar, it is a C
although UFCS should engage.
-manfred
class C{}
int main(){
void opOpAssign( string
On 05/15/2015 11:31 PM, Manfred Nowak wrote:
class C{}
int main(){
void opOpAssign( string op)( C a, C b){
}
C a, b;
a+= b;
}
https://issues.dlang.org/show_bug.cgi?id=8062
On Friday, May 15, 2015 21:31:35 Manfred Nowak via Digitalmars-d-learn wrote:
The following gives:
Error: 'a += b' is not a scalar, it is a C
although UFCS should engage.
-manfred
class C{}
int main(){
void opOpAssign( string op)( C a, C b){
}
C a, b;
a+= b;
}
Overloaded
The following gives:
Error: 'a += b' is not a scalar, it is a C
although UFCS should engage.
-manfred
class C{}
int main(){
void opOpAssign( string op)( C a, C b){
}
C a, b;
a+= b;
}
Just for fun:
// map, join, text, iota, writeln,
tuple
import std.algorithm, std.array, std.conv, std.range, std.stdio,
std.typecons;
void main()
{
iota(1,100)
.map!(a = tuple(a, a % 3 == 0 ? 0 : 4, a % 5 == 0 ? 8 : 4))
.map!(a = a[1] == a[2] ? a[0].text :
On Tuesday, 28 April 2015 at 10:46:54 UTC, Gary Willoughby wrote:
After reading the following thread:
http://forum.dlang.org/thread/nczgumcdfystcjqyb...@forum.dlang.org
I wondered if it was possible to write a classic fizzbuzz[1]
example using a UFCS chain? I've tried and failed.
[1]: http
On Tuesday, 28 April 2015 at 10:46:54 UTC, Gary Willoughby wrote:
After reading the following thread:
http://forum.dlang.org/thread/nczgumcdfystcjqyb...@forum.dlang.org
I wondered if it was possible to write a classic fizzbuzz[1]
example using a UFCS chain? I've tried and failed.
[1]: http
On Tuesday, 28 April 2015 at 11:03:09 UTC, bearophile wrote:
Gary Willoughby:
I wondered if it was possible to write a classic fizzbuzz[1]
example using a UFCS chain? I've tried and failed.
Is this OK?
void main() {
import std.stdio, std.algorithm, std.range, std.conv,
std.functional
After reading the following thread:
http://forum.dlang.org/thread/nczgumcdfystcjqyb...@forum.dlang.org
I wondered if it was possible to write a classic fizzbuzz[1]
example using a UFCS chain? I've tried and failed.
[1]: http://en.wikipedia.org/wiki/Fizz_buzz
Gary Willoughby:
I wondered if it was possible to write a classic fizzbuzz[1]
example using a UFCS chain? I've tried and failed.
Is this OK?
void main() {
import std.stdio, std.algorithm, std.range, std.conv,
std.functional;
100
.iota
.map!(i = ((i + 1) % 15).predSwitch
On Tuesday, 28 April 2015 at 10:46:54 UTC, Gary Willoughby wrote:
After reading the following thread:
http://forum.dlang.org/thread/nczgumcdfystcjqyb...@forum.dlang.org
I wondered if it was possible to write a classic fizzbuzz[1]
example using a UFCS chain? I've tried and failed.
[1]: http
using a UFCS chain? I've tried and failed.
[1]: http://en.wikipedia.org/wiki/Fizz_buzz
You can do this.
import std.range : iota;
import std.algorithm : map, each;
import std.typecons : Tuple, tuple;
import std.stdio : writeln;
Tuple!(size_t, string) fizzbuzz(size_t number) {
if (number
]
example using a UFCS chain? I've tried and failed.
[1]: http://en.wikipedia.org/wiki/Fizz_buzz
Here is another, hopefully readable, version with lambda built
on ternary operators:
-
import std.algorithm, std.conv, std.functional, std.range,
std.stdio;
void main () {
sequence !(q{n
...@forum.dlang.org
I wondered if it was possible to write a classic fizzbuzz[1]
example using a UFCS chain? I've tried and failed.
[1]: http://en.wikipedia.org/wiki/Fizz_buzz
Here is another, hopefully readable, version with lambda built
on ternary operators:
-
import std.algorithm, std.conv
On Tue, 14 Apr 2015 12:46:40 -0400, ketmar ket...@ketmar.no-ip.org wrote:
On Tue, 14 Apr 2015 11:20:38 -0400, bitwise wrote:
i believe that you can't do what you want in a way you want, 'cause UFCS
is not working for template args. but you can do this:
alias base(alias CC) = reflect
On Tue, 14 Apr 2015 12:52:19 -0400, anonymous anonym...@example.com
wrote:
abstract class Refl {
@property abstract string name() const;
immutable(Refl) base() const;
}
class ClassRefl(T) : Refl {
@property override string name() const {
return T.stringof;
}
On Tue, 14 Apr 2015 12:52:19 -0400, anonymous anonym...@example.com
wrote:
Parting thoughts:
I don't know where you're heading with this. But so far I don't see what
it would buy you over std.traits and TypeInfo/TypeInfo_Class.
Forgot to mention support for runtime reflection.
See here:
On Tue, 14 Apr 2015 11:20:38 -0400, bitwise wrote:
i believe that you can't do what you want in a way you want, 'cause UFCS
is not working for template args. but you can do this:
alias base(alias CC) = reflect!(CC.baseName());
...
static const(Refl) baseRefl = base!refl;
signature.asc
On Tuesday, 14 April 2015 at 15:20:37 UTC, bitwise wrote:
When I uncomment the nicer syntax, I get the errors below:
[1] Error: variable refl cannot be read at compile time
[2] Error: CTFE failed because of previous errors in base
class Base {
double d = 0.4;
}
class Test : Base {
Hi.
I've been building a reflection library for D, but I've hit a snag. If
anyone can help out, it would be much appreciated =D
In the example below, the second line of main() retrieves the reflection
of a base class. Everything is well and good. Now, I am trying to come up
with a more
EDIT: mis-formatted previous snippet
import std.algorithm, std.stdio, std.range, std.conv;
void main()
{
stdin
.byLine
.filter!(s = !s.empty s.front != '#’) // Filter with
this lambda function
.map!(s = s.to!double) // Map the strings to doubles
.array //
On Monday, 6 April 2015 at 18:00:46 UTC, Szymon Gatner wrote:
Why is that? The use case is to provide a set of convenience
extension methods to a basic interface. Say, given:
This is not the only use case, another (maybe even more common)
use is to allow pipeline programming.
Example from
!double) // Map the strings to doubles
.array // Sorting needs random access
.sort!((a, b) = a b) // Another lambda
.take(10) // Applyable to any range
.writeln;
}
Yup, I get that, still does not explain why UFCS can't extend
overload set. Especially if there would
) is not
callable using argument types (int)
does UFCS now work with method overloading? I know it is not a syntax
error because changing the name of int version of bar to bar2 and
calling foo.bar2(123) works fine.
You can't do this. UFCS cannot add overloads, it can only add whole
overload sets
error:
main.d(24): Error: function main.Foo.bar (string _param_0) is
not
callable using argument types (int)
does UFCS now work with method overloading? I know it is not a
syntax
error because changing the name of int version of bar to bar2
and
calling foo.bar2(123) works fine.
You can't do
(123); // === error
causing compilation error:
main.d(24): Error: function main.Foo.bar (string _param_0) is not
callable using argument types (int)
does UFCS now work with method overloading? I know it is not a syntax
error because changing the name of int version of bar to bar2 and
calling
)
does UFCS now work with method overloading? I know it is not a
syntax error because changing the name of int version of bar to
bar2 and calling foo.bar2(123) works fine.
On 03/10/2015 08:00 AM, John Colvin wrote:
On Tuesday, 10 March 2015 at 14:41:00 UTC, Logan Capaldo wrote:
On Monday, 9 March 2015 at 22:15:43 UTC, Ali Çehreli wrote:
You are right. I had the same observation at minute 11:27 below,
where I warn against UFCS with assumeWontThrow:
http
On 03/10/2015 01:40 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
.sort on an array is going to use the built-in sort property. You need to
use parens if you want to use the function in std.algorithm with an array
and UFCS, e.g.
arr.sort();
Didn't know that. Nice!
Another option
with the default less a b
without specifying !(a b)
.sort on an array is going to use the built-in sort property.
You need to
use parens if you want to use the function in std.algorithm
with an array
and UFCS, e.g.
arr.sort();
- Jonathan M Davis
On Monday, 9 March 2015 at 22:15:43 UTC, Ali Çehreli wrote:
You are right. I had the same observation at minute 11:27
below, where I warn against UFCS with assumeWontThrow:
http://www.youtube.com/watch?feature=player_detailpagev=oF8K4-bieaw#t=687
Ali
Sorry, which is right? I know ifThrown
On Tuesday, 10 March 2015 at 14:41:00 UTC, Logan Capaldo wrote:
On Monday, 9 March 2015 at 22:15:43 UTC, Ali Çehreli wrote:
You are right. I had the same observation at minute 11:27
below, where I warn against UFCS with assumeWontThrow:
http://www.youtube.com/watch?feature=player_detailpagev
.array
.sort
buildin arrays have a .sort-property that is called.
101 - 200 of 412 matches
Mail list logo
