Re: Disabling opAssign in a type disabled all the opAssigns of an aliased type?
On Tuesday, 31 July 2018 at 20:40:25 UTC, Steven Schveighoffer
wrote:
OK, so one thing to learn in D, you can't hijack stuff. When
you override a function, you have to override ALL the overloads.
I could have sworn I tested this before I wrote that it's a bug:
struct A {
void fun(int) {}
}
struct B {
A a;
alias a this;
@disable void fun(float);
}
void main() {
B b;
b.fun(3);
}
I was surprised to see it work, as I also thought it'd be a
hijacking issue. Turns out, it doesn't actually work. I must have
made a typo when I tried it. Ah well.
--
Simen
Re: Linking to dynamic druntime with dub
On Tuesday, 31 July 2018 at 14:27:18 UTC, rikki cattermole wrote: On 01/08/2018 2:18 AM, Nicholas Wilson wrote: On Tuesday, 31 July 2018 at 13:52:21 UTC, rikki cattermole wrote: On 01/08/2018 1:43 AM, Nicholas Wilson wrote: My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub? The same way you do it without dub. Except you pass the flags inside of "dflags". which is? (I usually use -link-defaultlib-shared with LDC hence the question with dub). No idea for dmd/gdc. But for LDC that would be (json): "dflags-ldc2": ["-link-defaultlib-shared"], Ahh, it turns out that loading shared libraries is not supported on OSX, wonderful.
Re: How to get an inout constructor working with a template wrapper
On Tuesday, 31 July 2018 at 21:54:54 UTC, Steven Schveighoffer wrote: Because inout is trying to combine all mutability modifiers into one. You want to specify the type, not the mutability, in the template parameter T. Ahhh. Ok I see... I think. This doesn't make sense. Can you post runnable code? Hehe, ok, so I fell victim to compiler generating an error for number 3 and then nothing else :p But yes you're right, if I comment out number 3 then 6 errors as well. Sorry my bad! When I go back to your original failing example, and replace the 3 with immutable(int)(3), it still fails. So for 3, compiler sees the instantiation: inout(W!(immutable int)) wrap(immutable(int)) If I understood you correctly? Yes. You can see for yourself with pragma msg: pragma(msg, typeof(t)); // immutable(int) But then what does it see in number 6, which works fine? I'm skeptical this is the case. Note that you may only see the instantiation error ONCE. Yep, you nailed that one. And why is 2 ok if 3 is not? because inout(const(T)) cannot have its inout removed. Because it may be an immutable? Or? But the complaint is really the issue. Clearly inout is specified, so it shouldn't complain that it isn't. Aye. I guess that's right. -Steve
Re: How to get an inout constructor working with a template wrapper
On 7/31/18 5:29 PM, aliak wrote: On Tuesday, 31 July 2018 at 12:37:34 UTC, Steven Schveighoffer wrote: On 7/29/18 1:46 PM, aliak wrote: On Sunday, 29 July 2018 at 12:45:48 UTC, Steven Schveighoffer wrote: Am I applying inout incorrectly? No, you need to apply it to wrap as well. I can't get run.dlang.io to work for posting a link, so here is my modified version: Ah bugger, right! Ok so there's no way to make explicit instantiation involving immutable work in the face of an inout parameter? Seems rather inconsistent no? It's not that there's no way, the issue is simply that you are explicitly instantiating incorrectly. wrap!int(immutable(int)(3)); Ok bear with me, but I'm really confused why "wrap!int(immutable(int)(3))" is "correct". Because inout is trying to combine all mutability modifiers into one. You want to specify the type, not the mutability, in the template parameter T. Essentially, if this were a normal function that takes only ints, you would write it once for all mutabilities: auto wrap(inout(int) x) Which works for mutable, const, or immutable int. This all seems very inconsistent: 1. wrap!(int)(3); // ok 2. wrap!(const int)(3); // ok 3. wrap!(immutable int)(3); // nope 4. wrap!(int)(3); // ok 5. wrap!(const int)(const(int)(3)); // ok 6. wrap!(immutable int)(immutable(int)(3)); // ok! This doesn't make sense. Can you post runnable code? When I go back to your original failing example, and replace the 3 with immutable(int)(3), it still fails. So for 3, compiler sees the instantiation: inout(W!(immutable int)) wrap(immutable(int)) If I understood you correctly? Yes. You can see for yourself with pragma msg: pragma(msg, typeof(t)); // immutable(int) But then what does it see in number 6, which works fine? I'm skeptical this is the case. Note that you may only see the instantiation error ONCE. And why is 2 ok if 3 is not? because inout(const(T)) cannot have its inout removed. And finally, why can't the compiler leave the inout there and then it doesn't need to complain about it? It has to strip inout to be consistent -- we want canonical types. It's the same reason immutable(const(int)) is just immutable(int), and const(const(const(int))) is just const(int). Having the original types be left in place would make for some weird rules. But the complaint is really the issue. Clearly inout is specified, so it shouldn't complain that it isn't. -Steve
Re: How to get an inout constructor working with a template wrapper
On Tuesday, 31 July 2018 at 12:37:34 UTC, Steven Schveighoffer wrote: On 7/29/18 1:46 PM, aliak wrote: On Sunday, 29 July 2018 at 12:45:48 UTC, Steven Schveighoffer wrote: Am I applying inout incorrectly? No, you need to apply it to wrap as well. I can't get run.dlang.io to work for posting a link, so here is my modified version: Ah bugger, right! Ok so there's no way to make explicit instantiation involving immutable work in the face of an inout parameter? Seems rather inconsistent no? It's not that there's no way, the issue is simply that you are explicitly instantiating incorrectly. wrap!int(immutable(int)(3)); -Steve Ok bear with me, but I'm really confused why "wrap!int(immutable(int)(3))" is "correct". This all seems very inconsistent: 1. wrap!(int)(3); // ok 2. wrap!(const int)(3); // ok 3. wrap!(immutable int)(3); // nope 4. wrap!(int)(3); // ok 5. wrap!(const int)(const(int)(3)); // ok 6. wrap!(immutable int)(immutable(int)(3)); // ok! So for 3, compiler sees the instantiation: inout(W!(immutable int)) wrap(immutable(int)) If I understood you correctly? But then what does it see in number 6, which works fine? And why is 2 ok if 3 is not? And finally, why can't the compiler leave the inout there and then it doesn't need to complain about it? Cheers, - Ali
Re: Small program producing binary with large filesize
On Tuesday, 31 July 2018 at 15:19:19 UTC, Dan Barbarito wrote: Hi all, I am starting to write a command line tool. So far it is a small (feature-wise) program but the file size is scaring me. It's already 13 megabytes, but I would expect it to be much smaller. Is it because I'm using 3 libraries so far? The libraries are: mir, vibe.d, and d2sqlite3. Would using these libraries be causing this file size? The code can be found here (http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone wants to take a look. I am simply running "dub build" to build the binary. I tried running "dub build --build=release" but that didn't effect the file size too much. Thanks! If you use LDC, release build and their full LTO (-flto=full), the resulting binary should get smaller. DFLAGS="-flto=full" dub build --compiler=ldc -b release As an example, dlang-tour is 53M in debug build with DMD, but with LTO + release + ldc it gets down to 6.2M. You also get a smaller build, if instead of using all of Vibe.d, you only use the subset of components you actually use, e.g. dependency "vibe-d:web" version="~>0.8"
Re: Where is TypeInfo_Class.m_init set
Sorry, scratch that, I forgot the `extern` before the dummy
global. After fixing that, I didn't quickly find a solution for
referencing the symbol in the .data.rel.ro section (LLVM asm,
e.g., `void* getInit() { return __asm!(void*)("movq
test.C.__init, %rax", "={rax}"); }` doesn't work either).
The compiler could emit the init symbol as regular global for
`-betterC` though.
---
This issue could also be tackled in the D ctor of the extern(C++)
class, by injecting the blit before the actual ctor body. C++
code wouldn't have to take care about that D-interop
incompatibility anymore (independent of -betterC).
Re: Disabling opAssign in a type disabled all the opAssigns of an aliased type?
On 7/30/18 2:30 PM, aliak wrote:
Is this a bug?
If not is there a workaround?
I would like for the alias this to function as a normal A type unless B
specifically disables certain features, but it seems weird that
disabling one opAssign disables all of them inside the aliases type but
not in the aliasing type?
struct A {
void opAssign(int) {}
}
struct B {
A a;
alias a this;
@disable void opAssign(float);
}
void main() {
B b;
b = 3;
}
Error: function `onlineapp.B.opAssign` is not callable because it is
annotated with @disable
OK, so one thing to learn in D, you can't hijack stuff. When you
override a function, you have to override ALL the overloads.
What you have done is defined opAssign as ONLY accepting a float, and
then disabling any calls to it.
This is obfuscated somewhat by the fact that 3 can be a float as well.
So even if you didn't disable the opAssign(float), it would still call
that function.
You can get around it by defining a forwarding function for the
overloads you want to let through:
@disable void opAssign(float);
auto opAssign(int x) { return a.opAssign(x); }
-Steve
Re: A vibe.d thing
On 7/31/18 1:22 PM, Russel Winder wrote: I have posted issue 2194 on the Vibe.d GitHub issues. https://github.com/vibe-d/vibe.d/issues/2194 Thanks, that should be good enough to figure out the bug in either your code or vibe.d -Steve
Re: Small program producing binary with large filesize
On 7/31/18 11:19 AM, Dan Barbarito wrote: Hi all, I am starting to write a command line tool. So far it is a small (feature-wise) program but the file size is scaring me. It's already 13 megabytes, but I would expect it to be much smaller. Is it because I'm using 3 libraries so far? The libraries are: mir, vibe.d, and d2sqlite3. Would using these libraries be causing this file size? The code can be found here (http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone wants to take a look. I am simply running "dub build" to build the binary. I tried running "dub build --build=release" but that didn't effect the file size too much. Thanks! D is statically linked, so the file size includes ALL the libraries (except for the C dynamic ones). Comparing this to C binaries, which are generally only linked dynamically, you will see much larger sizes. -Steve
Re: A vibe.d thing
I have posted issue 2194 on the Vibe.d GitHub issues. https://github.com/vibe-d/vibe.d/issues/2194 -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Where is TypeInfo_Class.m_init set
On Tuesday, 31 July 2018 at 01:16:29 UTC, Hakan Aras wrote: I was hoping it would be possible without tinkering with the compiler, but it doesn't seem to be the case. I've been playing around with LDC. There is an init symbol for classes, which is normally used as payload for the ClassInfo's m_init. I haven't been able to get its correct address though (I don't know enough about relocations), but it looks as if it could be gotten to work this way, see https://run.dlang.io/is/ZLDCpZ. Remove `-betterC` to see the address discrepancy causing the segfault, something like: init: 0x55dd229dc810 actual: 0x55dd229d3cf0
Re: A vibe.d thing
On Tue, 2018-07-31 at 11:54 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > > Understandable. I actually don't think you ever posted the real > message > that comes out, just a link to the source code, from which I found > it > wasn't obeying the mode variable. > > But now, it looks like it should be obeying the variable, yet you get > an > execption. Knowing what the actual message is would be helpful, at > least > for filing a bug or fixing it. Separate from the CVu Code Critique 112 stuff, I'll see if I can create a suitable test case to try and provide details. It seems like the right thing to do in the circumstances. :-) I guess I should post an issue on the vibe.d GitHub mainline repository rather than post things here. […] > What I mean is, I can't see why it would be throwing an exception > when > you supply the IOMode.once. But possibly if there is a timeout, it > might > be doing that. > > Or maybe there is another issue. Hopefully the actual exception message can reveal the truth! -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Where is TypeInfo_Class.m_init set
On Tuesday, 31 July 2018 at 03:42:15 UTC, Mike Franklin wrote: I would also like to be able to use `extern(C++)` classes without the runtime, but I haven't been able to allocate any time to it yet. If you're trying to use `extern(C++)` classes with betterC, and the compiler is complaining about `TypeInfo` give me an example illustrating the problem, and I might be able to submit a fix to the compiler. Mike It's working fine so far. Only problem is that the class needs to be compiletime constructible to get the initializer.
Re: A vibe.d thing
On 7/31/18 11:20 AM, Russel Winder wrote: On Tue, 2018-07-31 at 08:39 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: […] Hm.. it appears that there is a timeout exception thrown if there is no data within a certain time period. Are you getting that instead? To be honest, I am not sure. From a "I haven't looked at the library source, it's just a black box" all I can say is that if the buffer is 256 and there are >256 ubytes left the function returns but if there are <256 ubytes left an exception is thrown. I haven't checked the type of the exception or the exception message. Basically I got too annoyed that the documentation was sensible and the implementation wasn't meeting the documentation, I lost interest. Understandable. I actually don't think you ever posted the real message that comes out, just a link to the source code, from which I found it wasn't obeying the mode variable. But now, it looks like it should be obeying the variable, yet you get an execption. Knowing what the actual message is would be helpful, at least for filing a bug or fixing it. I'm not completely familiar with the mechanisms here, but it does appear to obey the other modes properly in this iteration of the library. I tried IOMode.all and IOMode.once but they both appeared to behave the same. I can't remember trying IOMode.immediate. What I mean is, I can't see why it would be throwing an exception when you supply the IOMode.once. But possibly if there is a timeout, it might be doing that. Or maybe there is another issue. -Steve
Re: A vibe.d thing
On Tue, 2018-07-31 at 08:39 -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: > […] > Hm.. it appears that there is a timeout exception thrown if there is > no > data within a certain time period. Are you getting that instead? To be honest, I am not sure. From a "I haven't looked at the library source, it's just a black box" all I can say is that if the buffer is 256 and there are >256 ubytes left the function returns but if there are <256 ubytes left an exception is thrown. I haven't checked the type of the exception or the exception message. Basically I got too annoyed that the documentation was sensible and the implementation wasn't meeting the documentation, I lost interest. > I'm not completely familiar with the mechanisms here, but it does > appear > to obey the other modes properly in this iteration of the library. I tried IOMode.all and IOMode.once but they both appeared to behave the same. I can't remember trying IOMode.immediate. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Small program producing binary with large filesize
Hi all, I am starting to write a command line tool. So far it is a small (feature-wise) program but the file size is scaring me. It's already 13 megabytes, but I would expect it to be much smaller. Is it because I'm using 3 libraries so far? The libraries are: mir, vibe.d, and d2sqlite3. Would using these libraries be causing this file size? The code can be found here (http://fossil.barbarito.me/finbot/zip/finbot.zip), if anyone wants to take a look. I am simply running "dub build" to build the binary. I tried running "dub build --build=release" but that didn't effect the file size too much. Thanks!
Re: Linking to dynamic druntime with dub
On 01/08/2018 2:18 AM, Nicholas Wilson wrote: On Tuesday, 31 July 2018 at 13:52:21 UTC, rikki cattermole wrote: On 01/08/2018 1:43 AM, Nicholas Wilson wrote: My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub? The same way you do it without dub. Except you pass the flags inside of "dflags". which is? (I usually use -link-defaultlib-shared with LDC hence the question with dub). No idea for dmd/gdc. But for LDC that would be (json): "dflags-ldc2": ["-link-defaultlib-shared"],
Re: Linking to dynamic druntime with dub
On Tuesday, 31 July 2018 at 13:52:21 UTC, rikki cattermole wrote: On 01/08/2018 1:43 AM, Nicholas Wilson wrote: My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub? The same way you do it without dub. Except you pass the flags inside of "dflags". which is? (I usually use -link-defaultlib-shared with LDC hence the question with dub).
Re: Linking to dynamic druntime with dub
On 01/08/2018 1:43 AM, Nicholas Wilson wrote: My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub? The same way you do it without dub. Except you pass the flags inside of "dflags".
Linking to dynamic druntime with dub
My application needs to load shared libraries: on Posix this is only supported with a shared druntime. How does one link to the dynamic druntime with dub?
Re: A vibe.d thing
On 7/31/18 7:49 AM, Russel Winder wrote: On Tue, 2018-07-31 at 13:10 +0200, Daniel Kozak via Digitalmars-d-learn wrote: On Fri, Jul 27, 2018 at 9:30 PM Steven Schveighoffer via Digitalmars-d-learn wrote: Maybe IOMode.immediate or .once? https://vibed.org/api/eventcore.driver/IOMode Oh, it looks like you specified once. Hm... that seems to me like it should work. Looks like IOMode is ignored: https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78cfd3aa 8246/core/vibe/core/drivers/libevent2_tcp.d#L285 So, no, there isn't a correct way to do this, it's unimplemented. It is implemented with vibe-core driver which should be default now https://github.com/vibe-d/vibe-core/blob/fae7d3e93d00d9636632aa0acf9ebc19ed9 f4a34/source/vibe/core/net.d#L665 Sadly as of vibe.d 0.8.4 the behaviour of read(buffer, IOMode) is to either fill the buffer completely or throw an exception. On the forum, Sönke has agreed it really does seem like a bug in the implementation. I found a workaround to the problem for my entry to CVu Code Critique 112, which actually is nicer code to the one that highlighted the problem – except that it relies on a property that has been marked deprecated. Deadline for entries is tomorrow, so I am not now in a position to change the article, it has to appear as it is now. Obviously once published, people are most welcome to write an article for CVu reporting how naïve/crap my code is, and providing better answers. Hm.. it appears that there is a timeout exception thrown if there is no data within a certain time period. Are you getting that instead? I'm not completely familiar with the mechanisms here, but it does appear to obey the other modes properly in this iteration of the library. -Steve
Re: How to get an inout constructor working with a template wrapper
On 7/29/18 1:46 PM, aliak wrote: On Sunday, 29 July 2018 at 12:45:48 UTC, Steven Schveighoffer wrote: Am I applying inout incorrectly? No, you need to apply it to wrap as well. I can't get run.dlang.io to work for posting a link, so here is my modified version: Ah bugger, right! Ok so there's no way to make explicit instantiation involving immutable work in the face of an inout parameter? Seems rather inconsistent no? It's not that there's no way, the issue is simply that you are explicitly instantiating incorrectly. wrap!int(immutable(int)(3)); -Steve
Re: append uninitialized elements to array
On 7/30/18 5:10 PM, Ali Çehreli wrote:
On 07/30/2018 10:40 AM, realhet wrote:
Hello,
I've already found out how to create an array with uninitialized
elements, but what I'm looking for is a way to append 16 uninitialized
ushorts to it and after I will it directly from 2 SSE registers.
The approximate array length is known at the start so I could be able
to do this by making an uninitializedArray and then doing the
appending manually, but I wonder if there is a way to do this with
array.reserve().
Basically it would be a thing that when this special uninitialized
append is happening and when the reserved array size is big enough, it
only increments the internal array length effectively.
Thanks
Knowing that the length of a slice is its first member:
void appendUninitialized(T)(ref T[] arr, size_t N = 1) {
arr.reserve(arr.length + N);
auto length_p = cast(size_t*)(&arr);
*length_p += N;
Instead of above 2 lines:
arr = arr.ptr[0 .. arr.length + N];
}
unittest {
ushort[] arr;
arr.appendUninitialized(2);
assert(arr.length == 2);
arr[0] = 1;
arr[1] = 2;
assert(arr == [ 1, 2 ]);
}
void main() {
int[] arr;
arr.appendUninitialized(100);
import std.stdio : writeln;
writeln(arr);
}
Ali
While this may work, it's unsafe. reserve reserves the space, but does
not adjust the allocated length. You have the potential for overwriting
data if you do this. I wouldn't recommend this method, especially if you
aren't sure of the source of array. The resulting array is also not
going to be appendable (it will reallocate on next append, even using
appendUninitialized).
-Steve
Re: A vibe.d thing
On Tue, 2018-07-31 at 13:10 +0200, Daniel Kozak via Digitalmars-d-learn wrote: > On Fri, Jul 27, 2018 at 9:30 PM Steven Schveighoffer via > Digitalmars-d-learn wrote: > > > > > > > Maybe IOMode.immediate or .once? > > > https://vibed.org/api/eventcore.driver/IOMode > > > > Oh, it looks like you specified once. Hm... that seems to me like it > > should work. > > > > Looks like IOMode is ignored: > > > > > > https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78cfd3aa > > 8246/core/vibe/core/drivers/libevent2_tcp.d#L285 > > > > So, no, there isn't a correct way to do this, it's unimplemented. > > > > -Steve > > > > It is implemented with vibe-core driver which should be default now > https://github.com/vibe-d/vibe-core/blob/fae7d3e93d00d9636632aa0acf9ebc19ed9 > f4a34/source/vibe/core/net.d#L665 Sadly as of vibe.d 0.8.4 the behaviour of read(buffer, IOMode) is to either fill the buffer completely or throw an exception. On the forum, Sönke has agreed it really does seem like a bug in the implementation. I found a workaround to the problem for my entry to CVu Code Critique 112, which actually is nicer code to the one that highlighted the problem – except that it relies on a property that has been marked deprecated. Deadline for entries is tomorrow, so I am not now in a position to change the article, it has to appear as it is now. Obviously once published, people are most welcome to write an article for CVu reporting how naïve/crap my code is, and providing better answers. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: A vibe.d thing
On Fri, Jul 27, 2018 at 9:30 PM Steven Schveighoffer via Digitalmars-d-learn wrote: > > > > Maybe IOMode.immediate or .once? > > https://vibed.org/api/eventcore.driver/IOMode > > Oh, it looks like you specified once. Hm... that seems to me like it > should work. > > Looks like IOMode is ignored: > > > https://github.com/vibe-d/vibe.d/blob/a9589d955f10bd076a67d47ace0c78cfd3aa8246/core/vibe/core/drivers/libevent2_tcp.d#L285 > > So, no, there isn't a correct way to do this, it's unimplemented. > > -Steve > It is implemented with vibe-core driver which should be default now https://github.com/vibe-d/vibe-core/blob/fae7d3e93d00d9636632aa0acf9ebc19ed9f4a34/source/vibe/core/net.d#L665
Re: How to best implement a DSL?
On 2018-07-28 16:59, Robert M. Münch wrote:
Hi, I'm seeking for ideas/comments/experiences how to best implement a
DSL in D.
What I would like to do is something like this:
... my D code ...
my-dsl {
... my multi-line DSL code ...
trade 100 shares(x) when (time < 20:00) and timingisright()
}
... my D code ...
Some things that circle in my head:
* Can the D parser somehow be missued for a DSL? So I can skip all the
generic features for types etc.?
Yes. But it would require your DSL to be syntactically valid D code (but
not semantically). DMD can be used as a library but is lacking quite a
bit i this regard. For example, you cannot get the original source code
from an AST node because the AST node only stores where in the source
code the node starts, not where it ends. Some AST nodes doesn't contain
location information at all. Also, unless you want to write the DSL in a
string literal you need to build some kind of pre-processor that
converts the DSL to valid D code.
--
/Jacob Carlborg
Re: A vibe.d thing
On 2018-07-27 21:02, Russel Winder wrote: I have posted to the vibe.d forum, but I hate forums, FYI, it's possible to access the vibe.d forum through a news reader by using the following URL [1]. This is noted at the bottom of the forum [2]. [1] nntp://forum.rejectedsoftware.com/ [2] http://forum.rejectedsoftware.com -- /Jacob Carlborg
Re: Why does not UFCS work for method defined inside unittest block?
On Tuesday, 31 July 2018 at 08:28:01 UTC, Ky-Anh Huynh wrote:
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) => sta.foo.bar;
auto g(string[] sta) {
return sta.foo.bar;
}
assert(f(["test"]) == ["test"]);
assert(g(["test"]) == ["test"]);
assert(["test"].h == ["test"]);
assert(["test"].g == ["test"]);
}
[/code]
(Src:
https://gist.github.com/icy/64ec1838929d448d9f874d1e8261e56a)
The last test will fail: Error: no property g for type string[]
Please advise.
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."
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 bottom of the above page:
"The reason why local symbols are not considered by UFCS, is to
avoid unexpected name conflicts."
If you need a function that's available for UFCS in a unittest
but is not there in a non-unittest context, use a version block:
version (unittest) {
auto fun(string[] s) { return s }
}
And if you need something with a context:
version (unittest) {
string delegate (string) test;
}
unittest {
string s1 = "foo";
test = s => s ~ s1;
"foo".test;
}
--
Simen
Re: Why does not UFCS work for method defined inside unittest block?
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
Why does not UFCS work for method defined inside unittest block?
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) => sta.foo.bar;
auto g(string[] sta) {
return sta.foo.bar;
}
assert(f(["test"]) == ["test"]);
assert(g(["test"]) == ["test"]);
assert(["test"].h == ["test"]);
assert(["test"].g == ["test"]);
}
[/code]
(Src:
https://gist.github.com/icy/64ec1838929d448d9f874d1e8261e56a)
The last test will fail: Error: no property g for type string[]
Please advise.
Thanks a lot.
Re: append uninitialized elements to array
Thank You!
Re: Disabling opAssign in a type disabled all the opAssigns of an aliased type?
On Tuesday, 31 July 2018 at 07:01:33 UTC, Simen Kjærås wrote: auto opAssign(T...)(T args) Admittedly, one rarely uses multi-argument opAssign, but for those rare occasions... :p -- Simen
Re: Disabling opAssign in a type disabled all the opAssigns of an aliased type?
On Monday, 30 July 2018 at 23:41:09 UTC, aliak wrote:
https://issues.dlang.org/show_bug.cgi?id=19130
Beautiful. :)
Would it take much to fix it up to use with templated opAssigns
as well?
I spent half an hour doing silly things, then I came up with this:
struct A {
void opAssign(int) {}
void opAssign(float) {}
void opAssign(T)(T t) if (is(T == string)) {}
}
struct B {
A a;
alias a this;
@disable void opAssign(float);
mixin(wrap!(B, "opAssign"));
auto opAssign(T...)(T args)
if (__traits(compiles, a.opAssign(args)))
{
// Look ma, no magic!
return a.opAssign(args);
}
}
unittest {
B b;
b = "Foo!";
}
(Remaining code as in my last post)
Yeah, it really is that simple, since specific overloads are
tried before templates.
--
Simen
