On Friday, 21 March 2025 at 13:41:18 UTC, Dennis wrote:
On Thursday, 20 March 2025 at 16:18:32 UTC, WhatMeWorry wrote:
Yup. That was the problem. Thank you. You guys are a sharp.
From dmd version 2.111, there will be a better error message in
this case.
https://github.com/dlang/dmd/pull/210
On Thursday, 20 March 2025 at 16:18:32 UTC, WhatMeWorry wrote:
Yup. That was the problem. Thank you. You guys are a sharp.
From dmd version 2.111, there will be a better error message in
this case.
https://github.com/dlang/dmd/pull/21046
Yup. That was the problem. Thank you. You guys are a sharp.
On Thursday, 20 March 2025 at 02:01:25 UTC, Jonathan M Davis
wrote:
On Wednesday, March 19, 2025 5:48:37 PM MDT H. S. Teoh via
Digitalmars-d-learn wrote:
I thought it was always a miss. :-D At least, it's never
worked for me every time I tried it. I always have to move
the UFCS functi
On Wednesday, March 19, 2025 5:48:37 PM MDT H. S. Teoh via Digitalmars-d-learn
wrote:
> On Wed, Mar 19, 2025 at 11:21:15PM +, monkyyy via Digitalmars-d-learn
> wrote:
> [...]
> > ufcs on local functions is hit or miss;
> [...]
>
> I thought it was always a miss. :
returned if no point b is found in the
> range
> ```
Where is wasFound declared? If you want UFCS syntax to work, wasFound
must be declared in global (module) scope. Otherwise, it will not be
considered for UFCS when resolving identifiers.
T
--
The cat owns the house; that's why the word "homeowner" has "meow" in it.
On Wed, Mar 19, 2025 at 11:21:15PM +, monkyyy via Digitalmars-d-learn wrote:
[...]
> ufcs on local functions is hit or miss;
[...]
I thought it was always a miss. :-D At least, it's never worked for me
every time I tried it. I always have to move the UFCS function to
module scope,
);
}
bool existPoint(Point b, int cost)
{
auto i = closed.countUntil(b); // Note: closed
if(i.wasFound()) // -1 is returned if no point b is
found in the range
```
ufcs on local functions is hit or miss; theres a old limitation
that d1 wanted or something; ussally
```
bool wasFound(I)(I result)
{
return(result != -1);
}
bool existPoint(Point b, int cost)
{
auto i = closed.countUntil(b);
if(wasFound(i)) // -1 is returned if no point b is
found in the range
```
The above compiles and executes successfully. But
On Friday, 6 January 2023 at 15:31:09 UTC, Salih Dincer wrote:
If you don't want to get the above output you should use the
previous example. But don't forget to connect alias and opCall.
For example, you can use @property in version 2.0.83 without
all the fanfare.
I forgot one thing: if yo
On Thursday, 5 January 2023 at 23:05:17 UTC, thebluepandabear
wrote:
them or remove them.
I agree, forbidding function call syntax would be a great
usecase for `@property`.
It will probably never get implemented though.
In older versions, it worked when printing values with writeln.
But
them or remove them.
I agree, forbidding function call syntax would be a great usecase
for `@property`.
It will probably never get implemented though.
On Thu, Jan 05, 2023 at 02:32:17PM +, Dom DiSc via Digitalmars-d-learn
wrote:
[...]
> I think this is really another usecase for @property: we should forbid the
> function call syntax for them (so one needs to use them like a variable).
[...]
> Properties are not functions. If you want a funct
On Wednesday, 4 January 2023 at 14:21:46 UTC, bauss wrote:
```d
class Foo {
int bar;
void setBar(Foo foo, int value) {
foo.bar = value;
}
}
void main() {
foo.setBar(100); // Not UFCS - just method call to the class
foo.setBar = 100; // Not UFCS - simply a setter function call
On Wednesday, 4 January 2023 at 14:21:46 UTC, bauss wrote:
On Wednesday, 4 January 2023 at 03:42:28 UTC, thebluepandabear
wrote:
...
My question is: is there a way to enforce UFCS-syntax?
None of your code actually uses UFCS.
This is UFCS:
```
class Foo {
int bar;
}
void setBar(Foo foo
On Wednesday, 4 January 2023 at 03:42:28 UTC, thebluepandabear
wrote:
...
My question is: is there a way to enforce UFCS-syntax?
None of your code actually uses UFCS.
This is UFCS:
```
class Foo {
int bar;
}
void setBar(Foo foo, int value) {
foo.bar = value;
}
void main
gt; d.name = "Poodle";
> In the code we can see that we have utilized UFCS (universal function
> call syntax)
UFCS is for calling free-standing functions as if they are member
functions. Since your example already uses member functions, this
feature is not UFCS. And I don't
` object:
```D
void main() {
Dog d = new Dog();
d.name = "Poodle";
writeln(d.name);
}
```
In the code we can see that we have utilized UFCS (universal
function call syntax) to set the properties for the object. This
feature is great. We have also used D's `@prope
On Friday, 17 June 2022 at 12:26:05 UTC, Antonio wrote:
UFCS vs Functional curring... nice battle :-)
**UFCS & CFTE** vs **Functional currying**... nice battle :-)
On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote:
On Thursday, 16 June 2022 at 23:59:06 UTC, Antonio wrote:
Is it there any way to apply UFCS on the returned method in
the same expression?
Nope. The way UFCS works is that allows you to call free
functions using member-function
On Friday, 17 June 2022 at 05:17:20 UTC, Tejas wrote:
On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote:
Nope. The way UFCS works is that allows you to call free
functions using member-function syntax, and member-function
syntax is always `object.memberName`, so UFCS only works for
On Friday, 17 June 2022 at 05:17:20 UTC, Tejas wrote:
On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote:
Nope. The way UFCS works is that allows you to call free
functions using member-function syntax, and member-function
syntax is always `object.memberName`, so UFCS only works for
On Friday, 17 June 2022 at 01:04:28 UTC, Paul Backus wrote:
Nope. The way UFCS works is that allows you to call free
functions using member-function syntax, and member-function
syntax is always `object.memberName`, so UFCS only works for
functions that have a name, not anonymous functions
On Thursday, 16 June 2022 at 23:59:06 UTC, Antonio wrote:
Is it there any way to apply UFCS on the returned method in the
same expression?
Nope. The way UFCS works is that allows you to call free
functions using member-function syntax, and member-function
syntax is always `object.memberName
expected 1 argument(s), not 2
```
I tried with some syntax change:
```d
void main()
{
doSomething("Hello")("X");
(doSomething("Hello"))("X"); // it works
"X".(doSomething("Hello"))(); // fails!!!
}
```
```onlineapp.d(14): Erro
On Wednesday, 1 September 2021 at 22:11:29 UTC, user1234 wrote:
On Wednesday, 1 September 2021 at 22:01:12 UTC, user1234 wrote:
```
ProcessPipes gnuplot () {
__gshared ProcessPipes pipe;
return pipe.pid ? pipe : (pipe =
pipeProcess("/usr/local/bin/gnuplot"));
}
```
user1234,
Thank
On Wednesday, 1 September 2021 at 22:01:12 UTC, user1234 wrote:
On Wednesday, 1 September 2021 at 20:59:15 UTC, james.p.leblanc
wrote:
[...]
The question is if there is a way to enable UFCS without such
wrapper
sorry my attention got stuck on the singleton.
So my suggestion is rather to
On Wednesday, 1 September 2021 at 20:59:15 UTC, james.p.leblanc
wrote:
[...]
The question is if there is a way to enable UFCS without such
wrapper
sorry my attention got stuck on the singleton.
So my suggestion is rather to only enable the ufcs style. This
highlights the fact that the class
e use of the UFCS in main() (without prefixing with
instantiated object's name
**gp** ). The gp prefix only needs to be in these wrappers that
exist in the module, not in the main().
The question is if there is a way to enable UFCS without such
wrapper
(see example in main() in origin
On Wednesday, 1 September 2021 at 16:02:47 UTC, james.p.leblanc
wrote:
Dear D-ers,
For simple plotting using a gnuplot process, I have created a
singleton object (a stripped
down minimal working example is below.)
[...]
**However, those wrapper functions in the gnuplot_mod module
looks a bi
ond uses a wrapper to allow use of the UFCS (uniform
function call syntax)
The ability to use the UFCS has the usual UFCS advantages,
additionally the coder
doesn't need to care about the actual name of the object's
instantiation.
**However, those wrapper functions in the gnuplot_mod
On Thursday, 8 July 2021 at 23:31:57 UTC, Antonio wrote:
"It works as described in the manual, not as expected" (from
MySQL haters club :-p) .
Yeah, 50/285 people answering the question "What language
features do you miss?" chose "UFCS for local symbols" in
On Thursday, 8 July 2021 at 22:31:49 UTC, Dennis wrote:
On Thursday, 8 July 2021 at 22:24:26 UTC, Antonio wrote:
I supossed that ```mfp(c,20)``` and ```c.mfp(20)``` should be
equivalent because UFCS in second example, but it is not...
why?
UFCS does not work for nested functions.
Functions
On Thursday, 8 July 2021 at 22:24:26 UTC, Antonio wrote:
onlineapp.d(9): Error: no property `mfp` for type `onlineapp.C`
I supossed that ```mfp(c,20)``` and ```c.mfp(20)``` should be
equivalent because UFCS in second example, but it is not... why?
https://dlang.org/spec/function.html#pseudo
On Thursday, 8 July 2021 at 22:24:26 UTC, Antonio wrote:
I supossed that ```mfp(c,20)``` and ```c.mfp(20)``` should be
equivalent because UFCS in second example, but it is not... why?
UFCS does not work for nested functions.
Functions declared in a local scope are not found when
searching
On Thursday, 8 July 2021 at 22:24:26 UTC, Antonio wrote:
I supossed that ```mfp(c,20)``` and ```c.mfp(20)``` should be
equivalent because UFCS in second example, but it is not... why?
UFCS only works with functions defined at top level, not nested
inside other functions. That's just h
t a;
int foo(int i) { return i + a; }
}
void main(){
auto mfp = (C self, int i)=>self.foo(i);
auto c = new C;
assert( c.mfp(20)==20);
}
```
onlineapp.d(9): Error: no property `mfp` for type `onlineapp.C`
I supossed that ```mfp(c,20)``` and ```c.mfp(20)``` should be
equivalent because U
On Tuesday, 26 January 2021 at 02:19:10 UTC, Tim wrote:
On Tuesday, 26 January 2021 at 01:38:45 UTC, Q. Schroll wrote:
On Tuesday, 26 January 2021 at 00:47:09 UTC, Tim wrote:
Hi all,
How can I change the following to a more D-like approach by
using UFCS?
double[3] result;
Unless you
On Tuesday, 26 January 2021 at 01:38:45 UTC, Q. Schroll wrote:
On Tuesday, 26 January 2021 at 00:47:09 UTC, Tim wrote:
Hi all,
How can I change the following to a more D-like approach by
using UFCS?
double[3] result;
Unless you have a good reason, use a slice and not a static
array
On Tuesday, 26 January 2021 at 00:47:09 UTC, Tim wrote:
Hi all,
How can I change the following to a more D-like approach by
using UFCS?
double[3] result;
Unless you have a good reason, use a slice and not a static array:
double[] result;
The result of std.array.array will be a slice
On Tuesday, 26 January 2021 at 00:47:09 UTC, Tim wrote:
Hi all,
How can I change the following to a more D-like approach by
using UFCS?
double[3] result;
Json json = res.readJson;
for(int i = 0; i < json.length; i++){
result[i] = json[i].to!double;
}
I'd prefer to do someth
Hi all,
How can I change the following to a more D-like approach by using
UFCS?
double[3] result;
Json json = res.readJson;
for(int i = 0; i < json.length; i++){
result[i] = json[i].to!double;
}
I'd prefer to do something like:
result = res.readJson[].map!(to!double);
Two differents types; Foo type and pointer type. Need function
overload foe each or just use ref and avoid pointer.
On Tuesday, 15 December 2020 at 20:38:04 UTC, Dave P. wrote:
The use case would be to define extension methods on a struct
outside of where the struct is defined. The extension method
mutates the state of the struct, so I want to ensure I am
modifying the original struct and not a copy. If it’s
:). I
am porting
an application I had written in C to D in betterC mode piece by
piece and there’s
a good number of functions where it’d be convenient to call them
via UFCs.
Thanks for answering my questions!
On Sunday, 13 December 2020 at 19:02:34 UTC, Dave P. wrote:
On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote:
On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote:
Do I have to write both and have one forward to the other for
more
complicated functions?
For free functions
On Tuesday, 15 December 2020 at 19:45:50 UTC, Q. Schroll wrote:
On Sunday, 13 December 2020 at 19:02:34 UTC, Dave P. wrote:
On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote:
On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote:
Do I have to write both and have one forward to
On Sunday, 13 December 2020 at 19:02:34 UTC, Dave P. wrote:
On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote:
On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote:
Do I have to write both and have one forward to the other for
more
complicated functions?
For free functions
On Sunday, 13 December 2020 at 18:44:20 UTC, Mike Parker wrote:
On Sunday, 13 December 2020 at 18:31:54 UTC, Dave P. wrote:
Do I have to write both and have one forward to the other for
more
complicated functions?
For free functions, yes.
Is there any way to write the function as a template
(){
printf("%d\n", x);
}
}
int main(){
Foo f;
f.fooey;
Foo* pf = &f;
pf.fooey;
f.report; // prints 2
return 0;
}
However, if I define it as a free function and try to invoke it
via UFCS,
it seems like I have to define it twice.
struct Foo {
int x;
f.fooey;
Foo* pf = &f;
pf.fooey;
f.report; // prints 2
return 0;
}
However, if I define it as a free function and try to invoke it
via UFCS,
it seems like I have to define it twice.
struct Foo {
int x;
void report(){
printf("%d\n", x);
}
}
voi
buffer[0..rq];
} catch(Throwable){return null;}
}
s = new Socket(AddressFamily.INET, SocketType.STREAM);
writeln(s.receive(8192)); // How slow is using as friendly
function?
Calling a function with or without UFCS makes absolutely no
difference to performance. The compiler will generate
// Função receive()
char[] receive(Socket socket, int size = 8192) nothrow {
try {
char[] buffer;
buffer.length = size;
int rq = socket.receive(buffer);
return buffer[0..rq];
} catch(Throwable){return null;}
}
s = ne
Given the code:
```
auto foo(alias A, string str)()
{
// do stuff
}
struct Bar
{
// members
}
Bar bar;
bar.foo!"hello"; // This is an error. Would have to do foo!(bar,
"hello")
```
Assuming that I haven't misunderstood or borked something, having
UFCS for
suddenly UFCS
ranges are possible! (I am as of yet not convinced that we
should, though)
--
Simen
This is basically what C++ calls "argument-dependent lookup."
Discussion about adding this sort of thing to D has come up
before on the forums [1], and iirc Walter has generally bee
the module) with __traits(parent), and import that:
mixin("import "~__traits(parent, R).stringof["module
".length..$]~";");
However, doing that in isInputRange doesn't help much. First, all
other range functions would have to do it, and second, just
impo
On Wednesday, 29 April 2020 at 08:34:53 UTC, Ogi wrote:
struct R {}
int front(R r) { return 42; }
void popFront(R r) {}
bool empty(R r) { return false; }
void main() {
import std.range.primitives : isInputRange;
static assert(isInputRange!R);
}
Error: static assert: `isInputRange!(R)`
On Wednesday, 29 April 2020 at 08:34:53 UTC, Ogi wrote:
struct R {}
int front(R r) { return 42; }
void popFront(R r) {}
bool empty(R r) { return false; }
void main() {
import std.range.primitives : isInputRange;
static assert(isInputRange!R);
}
Error: static assert: `isInputRange!(R)`
struct R {}
int front(R r) { return 42; }
void popFront(R r) {}
bool empty(R r) { return false; }
void main() {
import std.range.primitives : isInputRange;
static assert(isInputRange!R);
}
Error: static assert: `isInputRange!(R)` is false
Whats really weird is that if I replace isInp
owing not work? It works, if I move the
> >> 'prop' out of 'foo'.
> >
> > UFCS is only supported for module-level functions, as far as I
> > know.
> >
> >> ---
> >> struct S {
> >>
> >>ubyte[12] bar;
&
On Monday, 4 November 2019 at 20:46:41 UTC, H. S. Teoh wrote:
On Mon, Nov 04, 2019 at 07:51:26PM +, Tobias Pankrath via
Digitalmars-d-learn wrote:
Why does the following not work? It works, if I move the
'prop' out of 'foo'.
UFCS is only supported for module-level fu
On Tuesday, 5 November 2019 at 00:34:33 UTC, Nicholas Wilson
wrote:
https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/
struct S {
ubyte[12] bar;
}
alias I(alias f) = f;
bool foo (ref S s)
{
static bool prop(const(ubyte)[] f) {
return f.length >
On Monday, 4 November 2019 at 19:51:26 UTC, Tobias Pankrath wrote:
Why does the following not work? It works, if I move the 'prop'
out of 'foo'.
---
struct S {
ubyte[12] bar;
}
bool foo (ref S s)
{
static bool prop(const(ubyte)[] f) {
return f.length > 1;
}
return s
On Mon, Nov 04, 2019 at 07:51:26PM +, Tobias Pankrath via
Digitalmars-d-learn wrote:
> Why does the following not work? It works, if I move the 'prop' out of
> 'foo'.
UFCS is only supported for module-level functions, as far as I know.
> ---
>
Why does the following not work? It works, if I move the 'prop'
out of 'foo'.
---
struct S {
ubyte[12] bar;
}
bool foo (ref S s)
{
static bool prop(const(ubyte)[] f) {
return f.length > 1;
}
return s.bar[].prop;
}
---
Thanks!
On Sunday, 16 September 2018 at 10:55:43 UTC, berni wrote:
The problem is more general: you can only use top-level
symbols in UFCS.
You can use an identity alias template to bypass this:
https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/
(search for UFCS in the
The problem is more general: you can only use top-level symbols
in UFCS.
You can use an identity alias template to bypass this:
https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/
(search for UFCS in the page).
Good to know. :-)
On Sunday, 16 September 2018 at 09:46:15 UTC, berni wrote:
Where is my mistake?
Lambdas are not the issue here. The problem is more general: you
can only use top-level symbols in UFCS.
You can use an identity alias template to bypass this:
https://blog.thecybershadow.net/2015/04/28/the
property foo for type S
/usr/include/dmd/phobos/std/algorithm/iteration.d(1108):
instantiated from here: >FilterResult!(__lambda1, S[])
test.d(18):instantiated from here: filter!(S[])
When I replace the UFCS-Syntax in the lambda by a function call
it works:
[S(1),S(2),S(3),S(4),
On Tuesday, 31 July 2018 at 08:42:28 UTC, Simen Kjærås wrote:
From https://dlang.org/spec/function.html#pseudo-member:
"A free function can be called with a syntax that looks as if
the function were a member function of its first parameter
type."
[...]
Thanks a lot Simen :)
can be called with a syntax that looks as if the
function were a member function of its first parameter type."
A function defined in a function scope (which a unittest block
is), is not a free function, and so does not benefit from UFCS.
There is an explanation for why at the bot
dmd version that I'm using:
$ dmd --version
DMD64 D Compiler v2.081.1-dirty
Copyright (C) 1999-2018 by The D Language Foundation, All Rights
Reserved written by Walter Bright
Hi,
Can I define a new quick function to use inside a unittest block?
I have the following code:
[code]
auto foo(string[] sta) {
return sta;
}
auto bar(string[] sta) {
return sta;
}
auto h(string[] sta) {
return sta.foo.bar;
}
unittest {
import std.format;
auto f = (string[] sta)
to call member functions? UFCS only works with
free functions, meaning declared at module level.
https://dlang.org/spec/function.html#pseudo-member
I'm not intentionally trying to call member functions, no.
The functions are all static functions of a class, but the
chaining of them
On Friday, 13 July 2018 at 11:17:32 UTC, Radu wrote:
On Friday, 13 July 2018 at 11:12:47 UTC, Michael wrote:
On Friday, 13 July 2018 at 10:52:54 UTC, Radu wrote:
On Friday, 13 July 2018 at 10:21:54 UTC, Michael wrote:
[...]
Do you try to call member functions? UFCS only works with
free
On Friday, 13 July 2018 at 11:12:47 UTC, Michael wrote:
On Friday, 13 July 2018 at 10:52:54 UTC, Radu wrote:
On Friday, 13 July 2018 at 10:21:54 UTC, Michael wrote:
[...]
Do you try to call member functions? UFCS only works with free
functions, meaning declared at module level.
https
What am I missing here? I'm sure it's stupidly obvious but it
expects one argument, so I'm just calling it without
parentheses.
Do you try to call member functions? UFCS only works with free
functions, meaning declared at module level.
https://dlang.org/spec/function.html#pseu
tupidly obvious but it
expects one argument, so I'm just calling it without
parentheses.
Do you try to call member functions? UFCS only works with free
functions, meaning declared at module level.
https://dlang.org/spec/function.html#pseudo-member
Hello,
I am nesting some function calls, and I'm pretty used to making
use of D's Uniform Function Call Syntax, but I'm getting an error
if I try to convert this line:
createSet(createVector(langSize, index)).length;
which works, into this line:
createVector(langSize, index).createSet.le
On Thursday, 24 May 2018 at 22:03:38 UTC, aliak wrote:
It feels like the only difference between a no-arg function
that is @property and one that is not is that the former could
be invoked with optional parentheses and the latter should be
illegal with parentheses.
Edit: err... other way arou
On Tuesday, 22 May 2018 at 14:33:20 UTC, Jonathan M Davis wrote:
A free function with a single argument works just fine as a
setter property. e.g. you could do something like
void env(Tuple!(string, string)[] str)
{
// set environment variables
}
env = [tuple("foo", "bar")];
is perfectly
On Tuesday, 22 May 2018 at 13:59:16 UTC, Steven Schveighoffer
wrote:
The derailed plan was to leave alone the ability to call no-arg
functions without parentheses, but to REQUIRE @property to call
an argument-taking function with the assignment style.
See the DIP here: https://wiki.dlang.org/D
a big wart so we don't have to fix all of @property at
> least, but that should be fixed if fixing it does not crap on
> UFCS and @property free functions.
A free function with a single argument works just fine as a setter property.
e.g. you could do something like
void env(Tuple!(st
where fixing that will cause problems for @property free functions
because they all must take more that one parameter i assume.
It's quite a big wart so we don't have to fix all of @property at least,
but that should be fixed if fixing it does not crap on UFCS and
@property free functions.
for @property free
functions because they all must take more that one parameter i
assume.
It's quite a big wart so we don't have to fix all of @property at
least, but that should be fixed if fixing it does not crap on
UFCS and @property free functions.
On Monday, 21 May 2018 at 14:19:35 UTC, Steven Schveighoffer
wrote:
On 5/21/18 8:15 AM, SrMordred wrote:
Right, so this should´n be working I think.
struct SomeStruct
{
void foo(int);
}
SomeStruct s;
s.foo = 10;
I thought that only with @property this will work.
That was the plan, bu
es of @property actually ever
meaning anything like it was originally intended to mean are
pretty much zero. UFCS killed that.
- Jonathan M Davis
First of all thanks a lot for the response. It cleans something
for me. I need a few time to think.
t it only partially enforced
it, and of course code continued to be written without using it. So,
actually moving to enforcing everything with @property was slow.
And then UFCS happened, and that pretty much killed the whole thing. The
problem was twofold:
1. A number of folks just got in the
"%s %s".writefln = ("foo".tuple = "bar").expand;
lol
On Monday, 21 May 2018 at 11:38:12 UTC, SrMordred wrote:
what??
Here's another weird example:
```
void funWithUfcsAndPropertySyntax() {
import std.typecons : tuple;
"%s %s".writefln = ("foo".tuple = "bar").expand;
}
```
source:
https://github.com/Hackerpilot/Idiotmatic-D/blob/
On Monday, 21 May 2018 at 11:38:12 UTC, SrMordred wrote:
After all this time I saw this:
writeln = iota = 5;
what??
I never saw that before!
This is interesting, there is something useful that i can do
with this kind of call?
That's pretty cool, but at the same time this should be wiped of
On 5/21/18 8:15 AM, SrMordred wrote:
Right, so this should´n be working I think.
struct SomeStruct
{
void foo(int);
}
SomeStruct s;
s.foo = 10;
I thought that only with @property this will work.
That was the plan, but it got derailed.
Whoever wrote that original line of code, they ne
of code.". But something
like this make doubt about what happens in a piece of code. There
is static typing so I know that type a variable has, but I look
at a method calling and I ask: "Is it data field? No. Is it
property? No. Is it method? No. It's UFCS! Okay." And now I see
that UFCS can works the same way as a property!
Right, so this should´n be working I think.
struct SomeStruct
{
void foo(int);
}
SomeStruct s;
s.foo = 10;
I thought that only with @property this will work.
s intended
for and it's not really UFCS. It's was meant for properties that
are defined as functions.
struct SomeStruct
{
void foo(int);
}
SomeStruct s;
s.foo = 10;
It's kind of horrible syntax for what it is doing, where it isn't
obvious what is happening. Writeln and
After all this time I saw this:
writeln = iota = 5;
what??
I never saw that before!
This is interesting, there is something useful that i can do with
this kind of call?
t saying it's common, just something to be aware of that is
non-obvious (well it was not to me at least when I started
getting in to D). It's _probably_ not going to be a problem, but
if it ever is then it's going to be a very hard to detect one.
And sure, the solution is to j
tion, and proper testing would catch the rare case
where there would be a problem. If you're really worried about it, then just
don't use UFCS, but for better or worse, it seems to be the case that the
vast majority of D programmers use UFCS all the time and don't run into
problems
. That's
actually the only technical reason why UFCS is superior to the
normal function call syntax.
I think this may have hit the nail on the spot. So basically my
thinking is that if you're going to use UFCS inside a generic
function where you can't know what kind of metho
On Saturday, March 10, 2018 21:50:42 aliak via Digitalmars-d-learn wrote:
> What are the recommended guidelines for using/not using UFCS in
> writing generic libraries?
>
> I ask because if you have an internal generic free function that
> you use on types in a generic algorithm
1 - 100 of 432 matches
Mail list logo
