Re: date and timestamp
On Wednesday, 29 April 2020 at 22:22:04 UTC, guai wrote: Hi, forum I have two questions: 1) Why __DATE__ and __TIMESTAMP__ have these insane formats? "mmm dd " and "www mmm dd hh:mm:ss " I think its the first time in my life I encounter something like this. start with date, then print time, then the rest of the date - what? 2) Are those locale-specific? There was a similar discussion some time ago where Walter also explained the origin of these formats: https://forum.dlang.org/post/p4c8ka$2np$1...@digitalmars.com
Re: Can't recreate a range?
On Wednesday, 29 April 2020 at 20:43:20 UTC, Casey wrote:
void popFront()
{
}
I mean, it might be you messed up in posting this, but having an
empty popFront and expecting it to do something is a tad
optimistic.
Apart from that, it seems like the code should do what you want
it to. What's the value of count when the code asserts? I'm
afeared we'll need some code that actually compiles and shows off
the issue to give any more answers.
--
Simen
date and timestamp
Hi, forum I have two questions: 1) Why __DATE__ and __TIMESTAMP__ have these insane formats? "mmm dd " and "www mmm dd hh:mm:ss " I think its the first time in my life I encounter something like this. start with date, then print time, then the rest of the date - what? 2) Are those locale-specific?
Re: Can't recreate a range?
On Wednesday, 29 April 2020 at 20:43:20 UTC, Casey wrote: So, I'm trying to run some tests and I had code that looks similar to this: [...] I feel like I'm missing something obscure and it's driving me a bit batty. Any clue as to why this is happening? I'd like to not have to worry about creating new variable names between tests. To me, it seems like each unittest block is independent of each other and I haven't come across anything that contradicts that. However, I didn't find anything that confirms it either. Thanks. The code you posted looks correct to me. If you can post a complete example that reproduces the problem, it will be much easier for others to help you debug.
Can't recreate a range?
So, I'm trying to run some tests and I had code that looks
similar to this:
unittest
{
auto range =
readStream(File("test_data/multiple.xml").byLine);
int count = 0;
while (!range.empty)
{
count++;
range.popFront();
}
assert(count == 3);
}
However, if I have a second block above/below it doing the same
thing, the last assert will fail because in the second block it
appears the ranges have been joined together. E.g.:
unittest
{
auto range =
readStream(File("test_data/multiple.xml").byLine);
int count = 0;
while (!range.empty)
{
count++;
range.popFront();
}
assert(count == 3); // Passes
}
unittest
{
auto range =
readStream(File("test_data/another.xml").byLine);
int count = 0;
while (!range.empty)
{
count++;
range.popFront();
}
assert(count == 2); // Fails
}
To me, it looks like range is not being overwritten. The code
for readStream looks similar to this:
auto readStream(Range)(auto ref Range r) if
(isInputRange!(Unqual!Range))
{
struct StreamRange(Range)
{
alias R = Unqual!Range;
R _input;
this(R input)
{
this._input = input;
}
bool empty()
{
return this._input.empty;
}
string front()
{
// Do stuff...
}
void popFront()
{
}
}
return StreamRange!(Range)(r);
}
I feel like I'm missing something obscure and it's driving me a
bit batty. Any clue as to why this is happening? I'd like to
not have to worry about creating new variable names between
tests. To me, it seems like each unittest block is independent
of each other and I haven't come across anything that contradicts
that. However, I didn't find anything that confirms it either.
Thanks.
Re: Compililng C++ and D together without going mad
On Wednesday, 29 April 2020 at 10:25:31 UTC, Jan Hönig wrote:
In my pet project, I am using some C++ libraries. The main
file/function is also C++. All of it successfully compiles with
cmake. Now I want to add some functionality by calling my own D
functions (which use some other modules/projects/phobos).
My questions is, what is the "proper" building tool/way.
Do I extend my CMakeFile.txt with additional instructions,
which basically do a "dmd -c ...".
Do I use dub to compile the D part as a library, and use that
in the cmake file?
Do I use dub to compile the C++ part as well?
Surely somebody has done something similar.
Can you pinpoint me to some examples? I could go from there.
For mixed language project use Cmake only, you do not need to
involve dub.
You extend Cmake to compile D files. You add these files with the
contents.
CMakeDCompiler.cmake.in:
set(CMAKE_D_COMPILER "@CMAKE_D_COMPILER@")
set(CMAKE_D_COMPILER_LOADED 1)
set(CMAKE_D_SOURCE_FILE_EXTENSIONS
@CMAKE_D_SOURCE_FILE_EXTENSIONS@)
set(CMAKE_D_OUTPUT_EXTENSION @CMAKE_D_OUTPUT_EXTENSION@)
set(CMAKE_D_COMPILER_ENV_VAR "@CMAKE_D_COMPILER_ENV_VAR@")
CMakeDetermineDCompiler.cmake:
# Find the D compiler
find_program(
CMAKE_D_COMPILER
NAMES "ldc2"
HINTS "${CMAKE_SOURCE_DIR}"
DOC "LDC compiler"
)
mark_as_advanced(CMAKE_D_COMPILER)
set(CMAKE_D_SOURCE_FILE_EXTENSIONS d)
set(CMAKE_D_OUTPUT_EXTENSION .obj)
set(CMAKE_D_COMPILER_ENV_VAR "D")
# Configure variables set in this file for fast reload later on
configure_file(${CMAKE_CURRENT_LIST_DIR}/CMakeDCompiler.cmake.in
${CMAKE_PLATFORM_INFO_DIR}/CMakeDCompiler.cmake)
CMakeDInformation.cmake:
if(NOT CMAKE_D_COMPILE_OBJECT)
set(CMAKE_D_COMPILE_OBJECT "
${CMAKE_D_FLAGS} -c --of= ")
endif()
set(CMAKE_D_INFORMATION_LOADED 1)
CMakeTestDCompiler.cmake:
# For now just do nothing in here
set(CMAKE_D_COMPILER_WORKS 1 CACHE INTERNAL "")
Put these files somewhere and tell Cmake were to find them.
set(CMAKE_MODULE_PATH "${CMAKE_MODULE_PATH}"
${THE_PATH_TO_THE_FILES}" CACHE INTERNAL "")
You need to enable D language to use it with.
enable_language(D)
You can make this more complex but this will make you start
quickly. Now Cmake will compile D files as soon as it encounters
source files with the .d extension. You can gladly mix C++ and D
files and it will link them all together.
Jupyter notebook with Dlang
Today I have been toying around with jupyter. I wanted to know how it works (since I use it with Python all the time). I was trying to couple xeus[3] with drepl[4] together. But now (after using google and not duckduckgo), I have found multiple projects, which attempted similar things. It was mentioned before[1], however JupyterD was replaced with Jupyter-wire[2], which to my understanding is something similar to xeus[3], only in D. I have not found yet a jupyterized drepl. Are there any similar projects worth looking into? [1]: https://forum.dlang.org/post/hluqmwucwayuaeejg...@forum.dlang.org [2]: https://github.com/symmetryinvestments/jupyter-wire [3]: https://github.com/jupyter-xeus/xeus [4]: https://github.com/dlang-community/drepl
Re: Can’t use UFCS to create InputRange?
On Wednesday, 29 April 2020 at 12:23:11 UTC, Simen Kjærås wrote: Of course, nothing stops us from defining our own front, popFront and friends that combine the two approaches above: [...] We could conceivably add these to std.range.primitives (probably adding some constraints first), and 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 been opposed to it. If it were to be added as a library feature, it would probably have to be opt-in. [1] https://forum.dlang.org/post/mailman.123.1472818535.2965.digitalmar...@puremagic.com
Re: Compililng C++ and D together without going mad
On Wednesday, 29 April 2020 at 13:02:36 UTC, Jan Hönig wrote: On Wednesday, 29 April 2020 at 11:38:16 UTC, Johan wrote: LDC is a (somewhat complex) project with D and C++ code (and external C++ libraries). I think it will help you if your main() is in D (such that druntime is automatically initialized for you). https://github.com/ldc-developers/ldc -Johan Hmmm, a D main means i need to do quite some C++ bindings, with which I have 0 experience. I cannot even say if it will be possible. I will probably need: https://github.com/jupyter-xeus/xeus/blob/master/include/xeus/xkernel.hpp https://github.com/jupyter-xeus/xeus/blob/master/include/xeus/xkernel_configuration.hpp c++ stdlib's unique_ptr. And then i need to subclass a C++ class and extern this D subclass. It sounds easier to me, to manually initialize D's runtime (i imagine it being some function calls), build everything with C++, and just call D functions from C++. Manually initializing D's runtime is also possible. You need to call rt_init and rt_term: https://dlang.org/phobos/core_runtime.html#.rt_init What I meant is to - add a `int main()` in a D source file - rename your current `main` in the C++ source file to something like `the_real_main` - add a forward reference to the D file: `extern(C) int the_real_main();` - call `the_real_main` from the `main` in the D file That way you don't have to think about how to correctly initialize D's runtime. -Johan
Re: Compililng C++ and D together without going mad
On Wednesday, 29 April 2020 at 13:12:50 UTC, Johan wrote: Manually initializing D's runtime is also possible. You need to call rt_init and rt_term: https://dlang.org/phobos/core_runtime.html#.rt_init What I meant is to - add a `int main()` in a D source file - rename your current `main` in the C++ source file to something like `the_real_main` - add a forward reference to the D file: `extern(C) int the_real_main();` - call `the_real_main` from the `main` in the D file That way you don't have to think about how to correctly initialize D's runtime. -Johan I thought it was a good idea to ask in the forum! This actually helps me a lot, thanks!
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 12:26:02 UTC, Mike Parker wrote: On Wednesday, 29 April 2020 at 11:55:54 UTC, Sam E. wrote: I cannot find a D example using Win32 and the normal main function, and while it is working for simple message boxes, as soon as I want to do something slightly more complex (using a window), an hInstance has to be provided (as far as I understand, I'm not that knowledgeable with Win32). FYI, a quick google turned up this example: https://gist.github.com/caiorss/e8967d4d3dad522c82aab18ccd8f8304 It's C++ and not D, but the Win32 calls are the same. You should be able to adapt that to D fairly easily. Thank you a lot Mike, you were really helpful!
Re: Compililng C++ and D together without going mad
On Wednesday, 29 April 2020 at 13:02:36 UTC, Jan Hönig wrote: I will probably need: Also this thing: https://github.com/nlohmann/json
Re: Compililng C++ and D together without going mad
On Wednesday, 29 April 2020 at 11:38:16 UTC, Johan wrote: LDC is a (somewhat complex) project with D and C++ code (and external C++ libraries). I think it will help you if your main() is in D (such that druntime is automatically initialized for you). https://github.com/ldc-developers/ldc -Johan Hmmm, a D main means i need to do quite some C++ bindings, with which I have 0 experience. I cannot even say if it will be possible. I will probably need: https://github.com/jupyter-xeus/xeus/blob/master/include/xeus/xkernel.hpp https://github.com/jupyter-xeus/xeus/blob/master/include/xeus/xkernel_configuration.hpp c++ stdlib's unique_ptr. And then i need to subclass a C++ class and extern this D subclass. It sounds easier to me, to manually initialize D's runtime (i imagine it being some function calls), build everything with C++, and just call D functions from C++. Or do you think it is worth the hassle with bindings? I have done C++ bindings once,years ago in python and it was a not pleasent.
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 11:55:54 UTC, Sam E. wrote: I cannot find a D example using Win32 and the normal main function, and while it is working for simple message boxes, as soon as I want to do something slightly more complex (using a window), an hInstance has to be provided (as far as I understand, I'm not that knowledgeable with Win32). FYI, a quick google turned up this example: https://gist.github.com/caiorss/e8967d4d3dad522c82aab18ccd8f8304 It's C++ and not D, but the Win32 calls are the same. You should be able to adapt that to D fairly easily.
Re: Can’t use UFCS to create InputRange?
On Wednesday, 29 April 2020 at 09:16:58 UTC, user1234 wrote:
The static checker doesn't see your free funcs because to do so
it would have to import the whole module. (is it possible to do
that ? no idea.)
Of course it's possible! :) We can find the context of R (in this
case, 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
importing into function scope doesn't enable UFCS lookup.
Also your signature for the primitives are quite unusual (i.e
not idiomatic). Usually they dont take param. Usually we pass a
type that contains the member funcs matching to IsIntputRange.
You can see a good counterexample to this in
https://dlang.org/library/std/range/primitives/pop_front.html,
which defines popFront for regular arrays. However, that is the
one and only counterexample I know of.
Of course, nothing stops us from defining our own front, popFront
and friends that combine the two approaches above:
template front(R) {
auto front(R r) {
return __traits(getMember, __traits(parent, R),
"front")(r);
}
}
template popFront(R) {
auto popFront(R r) {
return __traits(getMember, __traits(parent, R),
"popFront")(r);
}
}
template empty(R) {
auto empty(R r) {
return __traits(getMember, __traits(parent, R),
"empty")(r);
}
}
We could conceivably add these to std.range.primitives (probably
adding some constraints first), and suddenly UFCS ranges are
possible! (I am as of yet not convinced that we should, though)
--
Simen
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 11:55:54 UTC, Sam E. wrote: On Wednesday, 29 April 2020 at 10:46:30 UTC, Mike Parker wrote: On Wednesday, 29 April 2020 at 10:44:48 UTC, Mike Parker wrote: Yeah, it says "WinMain is needed", which has never been true. THere's no need for the def file either. What's the way to get the hInstance without the use of WinMain? From Microsoft documentation: hInstance is the handle to the application instance. Get this value from the hInstance parameter of wWinMain. https://docs.microsoft.com/en-us/windows/win32/learnwin32/creating-a-window I cannot find a D example using Win32 and the normal main function, and while it is working for simple message boxes, as soon as I want to do something slightly more complex (using a window), an hInstance has to be provided (as far as I understand, I'm not that knowledgeable with Win32). auto hInstance = GetModuleHandleA(null); It's documented to return HMODULE, but HINSTANCE is the same thing (all the HANDLE types are void*). Passing null causes it to return the handle associated with the process, so for the executable "module", that's what you want (e.g., the process handle is the module handle). In a DLL, it wouldn't be, as the DLL would have a different handle than the process. https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulehandlea
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 10:46:30 UTC, Mike Parker wrote: On Wednesday, 29 April 2020 at 10:44:48 UTC, Mike Parker wrote: Yeah, it says "WinMain is needed", which has never been true. THere's no need for the def file either. What's the way to get the hInstance without the use of WinMain? From Microsoft documentation: hInstance is the handle to the application instance. Get this value from the hInstance parameter of wWinMain. https://docs.microsoft.com/en-us/windows/win32/learnwin32/creating-a-window I cannot find a D example using Win32 and the normal main function, and while it is working for simple message boxes, as soon as I want to do something slightly more complex (using a window), an hInstance has to be provided (as far as I understand, I'm not that knowledgeable with Win32).
Re: Compililng C++ and D together without going mad
On Wednesday, 29 April 2020 at 10:25:31 UTC, Jan Hönig wrote: In my pet project, I am using some C++ libraries. The main file/function is also C++. All of it successfully compiles with cmake. Now I want to add some functionality by calling my own D functions (which use some other modules/projects/phobos). My questions is, what is the "proper" building tool/way. Do I extend my CMakeFile.txt with additional instructions, which basically do a "dmd -c ...". Do I use dub to compile the D part as a library, and use that in the cmake file? Do I use dub to compile the C++ part as well? Surely somebody has done something similar. Can you pinpoint me to some examples? I could go from there. LDC is a (somewhat complex) project with D and C++ code (and external C++ libraries). I think it will help you if your main() is in D (such that druntime is automatically initialized for you). https://github.com/ldc-developers/ldc -Johan
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 10:44:48 UTC, Mike Parker wrote: On Wednesday, 29 April 2020 at 10:26:40 UTC, Sam E. wrote: I took the WinMain from https://wiki.dlang.org/D_for_Win32, should that documentation be updated to use a normal main function instead? Also the details regarding linker flags may be a good addition to that wiki page. Yeah, it says "WinMain is needed", which has never been true. THere's no need for the def file either.
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 10:27:35 UTC, Sam E. wrote: To be honest, I haven't yet found the way to switch between -m32 and -m64 (or other) via dub :) Pass the -a flag on the dub command line with the appropriate argument: For -m32: -ax86 For -m32mscoff: -ax86_mscoff For -m64: -ax86_64 Note that on 64-bit Windows, recent versions of dub will be calling the compiler with -m64 by default.
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 10:26:40 UTC, Sam E. wrote: I took the WinMain from https://wiki.dlang.org/D_for_Win32, should that documentation be updated to use a normal main function instead? Also the details regarding linker flags may be a good addition to that wiki page. Yeah, it says "WinMain is needed", which has never been true.
Re: Building Win32 application via dub
On 29/04/2020 10:27 PM, Sam E. wrote: To be honest, I haven't yet found the way to switch between -m32 and -m64 (or other) via dub :) $ dub build --arch=x86 $ dub build --arch=x86_64
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 10:26:40 UTC, Sam E. wrote: Really, there's no reason at all to use WinMain. Just create a standard main function. Then you don't need to worry about manually initializing the runtime and you'll have a console window by default. You can always turn it off in anything you want to ship without the console by adding the appropriate dflags to your dub file: -L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTStartup Conversely, you can get the console window in a WinMain app with: -L/SUBSYSTEM:CONSOLE -L/ENTRY:WinMainCRTStartup Though, again, there's really no reason to use WinMain. I took the WinMain from https://wiki.dlang.org/D_for_Win32, should that documentation be updated to use a normal main function instead? Also the details regarding linker flags may be a good addition to that wiki page. Just to confirm what Mike was saying: removing the WinMain completely and using a normal main function with calls to Win32 functions builds and works perfectly fine, that's a way nicer approach.
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 10:12:29 UTC, Mike Parker wrote: Most likely because you're calling writeln before initializing the runtime. Of course, that was it, thanks for the help Mike! Also, when using WinMain, you aren't going to see any output from writeln because you won't have a console window. The linker will create a "Windows subsystem" app rather than a "Console subsystem". Thanks again, you're right, I didn't realize that would be the case. Really, there's no reason at all to use WinMain. Just create a standard main function. Then you don't need to worry about manually initializing the runtime and you'll have a console window by default. You can always turn it off in anything you want to ship without the console by adding the appropriate dflags to your dub file: -L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTStartup Conversely, you can get the console window in a WinMain app with: -L/SUBSYSTEM:CONSOLE -L/ENTRY:WinMainCRTStartup Though, again, there's really no reason to use WinMain. I took the WinMain from https://wiki.dlang.org/D_for_Win32, should that documentation be updated to use a normal main function instead? Also the details regarding linker flags may be a good addition to that wiki page.
Compililng C++ and D together without going mad
In my pet project, I am using some C++ libraries. The main file/function is also C++. All of it successfully compiles with cmake. Now I want to add some functionality by calling my own D functions (which use some other modules/projects/phobos). My questions is, what is the "proper" building tool/way. Do I extend my CMakeFile.txt with additional instructions, which basically do a "dmd -c ...". Do I use dub to compile the D part as a library, and use that in the cmake file? Do I use dub to compile the C++ part as well? Surely somebody has done something similar. Can you pinpoint me to some examples? I could go from there.
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 10:19:39 UTC, Ahmet Sait wrote: Though the program built with dub is now crashing at runtime when calling `writeln` within the `WinMain` block. Back then when I was trying to use writeln (or any standard output function like printf)in a non-console app in Windows it used to crash, I don't know exact reason behind it but you might want to use AllocConsole to workaround it. If the same code works fine with -m32 but not -m32mscoff (or -m64) then I have no idea. To be honest, I haven't yet found the way to switch between -m32 and -m64 (or other) via dub :)
Re: Building Win32 application via dub
Though the program built with dub is now crashing at runtime when calling `writeln` within the `WinMain` block. Back then when I was trying to use writeln (or any standard output function like printf)in a non-console app in Windows it used to crash, I don't know exact reason behind it but you might want to use AllocConsole to workaround it. If the same code works fine with -m32 but not -m32mscoff (or -m64) then I have no idea.
Re: Building Win32 application via dub
On Wednesday, 29 April 2020 at 09:43:53 UTC, Sam E. wrote: Though the program built with dub is now crashing at runtime when calling `writeln` within the `WinMain` block. The exception error is: Exception has occurred: W32/0xc096 Unhandled exception at 0x7FF643C5AFE4 in test-win32.exe: 0xC096: Privileged instruction. So it feels that something else is missing or wrong. Any pointer would be helpful :) Screenshot of the call site: https://postimg.cc/5YtY9PRQ Screenshot of the expection: https://postimg.cc/K3vKz0pg Most likely because you're calling writeln before initializing the runtime. Also, when using WinMain, you aren't going to see any output from writeln because you won't have a console window. The linker will create a "Windows subsystem" app rather than a "Console subsystem". Really, there's no reason at all to use WinMain. Just create a standard main function. Then you don't need to worry about manually initializing the runtime and you'll have a console window by default. You can always turn it off in anything you want to ship without the console by adding the appropriate dflags to your dub file: -L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTStartup Conversely, you can get the console window in a WinMain app with: -L/SUBSYSTEM:CONSOLE -L/ENTRY:WinMainCRTStartup Though, again, there's really no reason to use WinMain. The /SUBSYSTEM flag works with the default OPTLINK linker and Microsoft's link.exe. You don't need the /ENTRY flag with optlink. It will do the right thing based on the /SUBSYSTEM flag. https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=vs-2019 https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2019
Re: Building Win32 application via dub
On Tuesday, 28 April 2020 at 20:18:29 UTC, Adam D. Ruppe wrote: On Tuesday, 28 April 2020 at 19:25:06 UTC, Sam E. wrote: I'm a bit surprised to see a linking error given that building directly from `dmd` seems to work fine without any flag. dmd directly uses -m32 whereas dub by default uses -m32mscoff to dmd. The mscoff linker (also used for -m64 btw) doesn't add the user32 library by default, you must explicitly add it. So with dub just add the user32 library to your config file and it should be ok. (I don't recall the syntax for that off the top of my head) Thanks, that seems to link after adding `libs "user32"` to my `dub.sdl` file. Though the program built with dub is now crashing at runtime when calling `writeln` within the `WinMain` block. The exception error is: Exception has occurred: W32/0xc096 Unhandled exception at 0x7FF643C5AFE4 in test-win32.exe: 0xC096: Privileged instruction. So it feels that something else is missing or wrong. Any pointer would be helpful :) Screenshot of the call site: https://postimg.cc/5YtY9PRQ Screenshot of the expection: https://postimg.cc/K3vKz0pg
Re: Can’t use UFCS to create InputRange?
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)` is false
Whats really weird is that if I replace isInputRange with its
definition from std.range.primitives, it returns true:
import std;
struct R {}
int front(R r) { return 42; }
void popFront(R r) {}
bool empty(R r) { return false; }
void main() {
static assert(is(typeof(R.init) == R)
&& is(ReturnType!((R r) => r.empty) == bool)
&& is(typeof((return ref R r) => r.front))
&& !is(ReturnType!((R r) => r.front) == void)
&& is(typeof((R r) => r.popFront)));
}
This compiles.
What’s going on here?
The static checker doesn't see your free funcs because to do so
it would have to import the whole module. (is it possible to do
that ? no idea.)
Also your signature for the primitives are quite unusual (i.e not
idiomatic). Usually they dont take param. Usually we pass a type
that contains the member funcs matching to IsIntputRange.
Re: Can’t use UFCS to create InputRange?
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)` is false
What’s going on here?
The template IsInputRange is in the std.range.primitives module,
and thus can't see the front, popFront and empty definitions in
your module.
--
Simen
Re: GtkD - how to list 0..100K strings
Continuing this in the GtkD mailing list: https://forum.gtkd.org/groups/GtkD/thread/1370/
Can’t use UFCS to create InputRange?
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 isInputRange with its
definition from std.range.primitives, it returns true:
import std;
struct R {}
int front(R r) { return 42; }
void popFront(R r) {}
bool empty(R r) { return false; }
void main() {
static assert(is(typeof(R.init) == R)
&& is(ReturnType!((R r) => r.empty) == bool)
&& is(typeof((return ref R r) => r.front))
&& !is(ReturnType!((R r) => r.front) == void)
&& is(typeof((R r) => r.popFront)));
}
This compiles.
What’s going on here?
