Re: is this a betterC bug ?
On Tuesday, 14 August 2018 at 17:49:32 UTC, Mike Franklin wrote: On Tuesday, 14 August 2018 at 17:22:42 UTC, Seb wrote: FYI: staticArray will be part of 2.082, it already works with dmd-nightly: That just seems wrong. Isn't the fact that `staticArray` is needed a bug in the compiler? I think the compiler could have lowered to something like that automatically to avoid the library workaround. Mike It's not a bug, it's all about how the type system is set up. The type of an array literal expression like `[1, 2, 3]` is `int[]` (a slice of an array of ints), so no matter if you do: auto readonly(T)(const(T)[] x) { return x; } auto arr1 = [1, 2, 3]; auto arr2 = [1, 2, 3].readonly; constarr3 = [1, 2, 3]; enum arr4 = [1, 2, 3]; static immutable arr5 = [1, 2, 3]; scopearr6 = [1, 2, 3]; In all instances the type will be `int[]` modulo type qualifiers. Static arrays are completely different types, that just happen to accept assignments from slices. Their two defining properties are: 1. Their length is fixed at compile-time, meaning that you can do: import std.array, std.meta; auto x = [1, 2, 3, 4, 5].staticArray; enum length = x.length; pragma (msg, length); alias seq = AliasSeq!(0, 42, length); static foreach (i; 0 .. length) { } static foreach (i; seq) { } 2. Where slices are reference types, static arrays are value types which means that each assignment will copy an entire array. Basically they behave like a `struct { int _arr_0 = 0, _arr_1 = 1, _arr_2 = 2; }`. https://run.dlang.io/is/iD9ydu
Re: is this a betterC bug ?
On Wednesday, 15 August 2018 at 08:14:53 UTC, Petar Kirov [ZombineDev] wrote: https://run.dlang.io/is/iD9ydu I made a typo in one of the comments. Here's the fixed version: https://run.dlang.io/is/HRqYcZ
tryTo: non-throwing variant of std.conv.to
Have anybody thought about non-throwing variants of std.conv.to typically named `tryTo` similar to what Folly https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throwing-interfaces does, for instance, as tryTo(str).then([](int i) { use(i); }); ? Would it be sane to add these to std.conv alongside existing std.conv.to so that underlying logic in std.conv.to can be reused? If so, AFAICT, existing std.conv.to should be implemented on top of std.conv.tryTo.
Re: tryTo: non-throwing variant of std.conv.to
On Wednesday, 15 August 2018 at 09:21:29 UTC, Per Nordlöw wrote: Have anybody thought about non-throwing variants of std.conv.to typically named `tryTo` similar to what Folly https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throwing-interfaces does, for instance, as tryTo(str).then([](int i) { use(i); }); ? Would it be sane to add these to std.conv alongside existing std.conv.to so that underlying logic in std.conv.to can be reused? If so, AFAICT, existing std.conv.to should be implemented on top of std.conv.tryTo. Well, for now you can use `ifThrown` from std.exception: https://dlang.org/phobos/std_exception.html#ifThrown --- "foo".to!int.ifThrown(42) --- https://run.dlang.io/is/nlZKOw Usage of optionals/nullables is sadly not very common in Phobos and I think if we want everything to work nicely, we probably have to start a new standard library (or do massive refactorings of the existing one.)
Re: tryTo: non-throwing variant of std.conv.to
On Wednesday, August 15, 2018 3:21:29 AM MDT Per Nordlöw via Digitalmars-d- learn wrote: > Have anybody thought about non-throwing variants of std.conv.to > typically named `tryTo` > similar to what Folly > > https://github.com/facebook/folly/blob/master/folly/docs/Conv.md#non-throw > ing-interfaces > > does, for instance, as > > tryTo(str).then([](int i) { use(i); }); > > ? > > Would it be sane to add these to std.conv alongside existing > std.conv.to so that underlying logic in std.conv.to can be reused? > > If so, AFAICT, existing std.conv.to should be implemented on top > of std.conv.tryTo. Yes. I've considered writing a set of conversion functions like std.conv.to which return a Nullable!T (where the target type is T) and return Nullable!T.init when the conversion fails rather than throwing, and they really should be in std.conv alongside to, reusing logic as much as reasonably possible, but it's not a small project. It's come up off and on for a while now, so I expect that someone will do it eventually (and I may at some point if no one else does), but obviously, someone has to actually take the time to do it, or it's not going to happen. - Jonathan M Davis
Re: is this a betterC bug ?
On Wednesday, 15 August 2018 at 08:14:53 UTC, Petar Kirov [ZombineDev] wrote: It's not a bug, it's all about how the type system is set up. The type of an array literal expression like `[1, 2, 3]` is `int[]` (a slice of an array of ints), so no matter if you do: auto readonly(T)(const(T)[] x) { return x; } auto arr1 = [1, 2, 3]; auto arr2 = [1, 2, 3].readonly; constarr3 = [1, 2, 3]; enum arr4 = [1, 2, 3]; static immutable arr5 = [1, 2, 3]; scopearr6 = [1, 2, 3]; In all instances the type will be `int[]` modulo type qualifiers. Static arrays are completely different types, that just happen to accept assignments from slices. Their two defining properties are: 1. Their length is fixed at compile-time, meaning that you can do: import std.array, std.meta; auto x = [1, 2, 3, 4, 5].staticArray; enum length = x.length; pragma (msg, length); alias seq = AliasSeq!(0, 42, length); static foreach (i; 0 .. length) { } static foreach (i; seq) { } 2. Where slices are reference types, static arrays are value types which means that each assignment will copy an entire array. Basically they behave like a `struct { int _arr_0 = 0, _arr_1 = 1, _arr_2 = 2; }`. https://run.dlang.io/is/iD9ydu Thanks for the detailed explanation; it make sense now. Mike
Re: Concat enum of strings into one string
On Tuesday, 14 August 2018 at 16:03:05 UTC, vit wrote: import std.traits : EnumMembers; import std.string : join; import std.algorithm : map; pragma(msg, [EnumMembers!Type].map!(x => cast(string)x).join(" ")); Thank you! Jonathan M Davis, I understood.
Re: tryTo: non-throwing variant of std.conv.to
On Wednesday, 15 August 2018 at 09:26:26 UTC, Seb wrote: If so, AFAICT, existing std.conv.to should be implemented on top of std.conv.tryTo. Well, for now you can use `ifThrown` from std.exception: https://dlang.org/phobos/std_exception.html#ifThrown --- "foo".to!int.ifThrown(42) But the whole idea is to avoid both throwing and catching exceptions at all. As this results in orders of magnitudes of drop in performance for the throwing case. That's the reason why Folly has this aswell. Thanks anyway, Seb.
Re: tryTo: non-throwing variant of std.conv.to
On Wednesday, 15 August 2018 at 10:38:23 UTC, Jonathan M Davis wrote: Would it be sane to add these to std.conv alongside existing std.conv.to so that underlying logic in std.conv.to can be reused? If so, AFAICT, existing std.conv.to should be implemented on Put something together to get early feedback on the idea: https://github.com/dlang/phobos/pull/6665
Array!bool -> Chunks -> foreach: out of bounds
core.exception.AssertError@/src/phobos/std/container/array.d(1667): Using out of bounds indexes on an Array Should this code[1] really try to access something out of bounds and assert? Also: shouldn't this assertion[2] be perhaps inside `version(D_NoBoundsChecks){} else { ... }` block? Kind regards, Elias [1] https://run.dlang.io/is/l6eyCF [2] https://github.com/dlang/phobos/blob/v2.081.2/std/container/array.d#L1667
Convert output of map() to array of strings
Hello, I have the following code: string[] list; string text; // ... enum pattern = ctRegex!`^[0-9]+$`; list = text.split('\n').map!(line => line.matchFirst(pattern).hit); Compiler says that it can't convert result of map function to string[]... What I want: 1. Split some text into lines using separator '\n'. 2. Apply to each line a regex pattern and extract matched text. 3. Result of these operations assign to variable of type string[]. Tried to do this: list = text.split('\n').map!(line => line.matchFirst(pattern).hit).to!(string[]); but no success...
Re: Convert output of map() to array of strings
On Wednesday, 15 August 2018 at 13:53:02 UTC, Andrey wrote: Hello, I have the following code: string[] list; string text; // ... enum pattern = ctRegex!`^[0-9]+$`; list = text.split('\n').map!(line => line.matchFirst(pattern).hit); Compiler says that it can't convert result of map function to string[]... The result of `map` is a lazily-evaluated range. To convert it to an array, use `std.array.array`: import std.array: array; //... list = text .split('\n') .map!(line => line.matchFirst(pattern).hit) .array;
Re: Array!bool -> Chunks -> foreach: out of bounds
It's a bug: auto s=ar[]; s.popFront(); auto s1=s[0..0]; //out of bounds
Re: Array!bool -> Chunks -> foreach: out of bounds
On Wednesday, 15 August 2018 at 15:13:50 UTC, Kagamin wrote: It's a bug: Is it a known one?
A devil self reference
Hi all. Finally, I arrived at something like this: ´´´ void main() { S!(sarr)[] sarr; } struct S(alias Reference) { size_t id() in { // not static assert, only because a pointer is never known in advance assert(Reference.ptr <= &this); } do { return &this - Reference.ptr; } } ´´´ Of course, this does not compile, because I try to use an identifier before I defined it. However, the reason I dare to ask is, that all the stuff with the weird self reference is compile time known. So, is there a possibility to define something like the thing above?
Re: A devil self reference
On Wednesday, 15 August 2018 at 16:40:49 UTC, Alex wrote: Hi all. Finally, I arrived at something like this: ´´´ void main() { S!(sarr)[] sarr; } struct S(alias Reference) { size_t id() in { // not static assert, only because a pointer is never known in advance assert(Reference.ptr <= &this); } do { return &this - Reference.ptr; } } ´´´ Of course, this does not compile, because I try to use an identifier before I defined it. However, the reason I dare to ask is, that all the stuff with the weird self reference is compile time known. So, is there a possibility to define something like the thing above? containment in a container is also wanted... struct Container { S!(sarr)[] sarr; } but also not possible in this form because of a circular reference.
Re: Array!bool -> Chunks -> foreach: out of bounds
On 8/15/18 12:27 PM, 0xEAB wrote: On Wednesday, 15 August 2018 at 15:13:50 UTC, Kagamin wrote: It's a bug: Is it a known one? Nope. And I figured out the problem. Will submit a fix. -Steve
Re: Array!bool -> Chunks -> foreach: out of bounds
On 8/15/18 2:05 PM, Steven Schveighoffer wrote: On 8/15/18 12:27 PM, 0xEAB wrote: On Wednesday, 15 August 2018 at 15:13:50 UTC, Kagamin wrote: It's a bug: Is it a known one? Nope. And I figured out the problem. Will submit a fix. https://issues.dlang.org/show_bug.cgi?id=19171 -Steve
Re: Array!bool -> Chunks -> foreach: out of bounds
On 8/15/18 2:12 PM, Steven Schveighoffer wrote: https://issues.dlang.org/show_bug.cgi?id=19171 PR: https://github.com/dlang/phobos/pull/ -Steve
Re: A devil self reference
On Wednesday, August 15, 2018 10:40:49 AM MDT Alex via Digitalmars-d-learn wrote: > Hi all. > Finally, I arrived at something like this: > > ´´´ > void main() > { > S!(sarr)[] sarr; > } > > struct S(alias Reference) > { > size_t id() > in > { > // not static assert, only because a pointer is never known in > advance > assert(Reference.ptr <= &this); > } > do > { > return &this - Reference.ptr; > } > } > ´´´ > > Of course, this does not compile, because I try to use an > identifier before I defined it. > > However, the reason I dare to ask is, that all the stuff with the > weird self reference is compile time known. > > So, is there a possibility to define something like the thing > above? What are you actually trying to do? Aside from the circular reference issues, using the address of a struct like that is very risky, because if the struct is ever moved, it will change. Also, even if the circular reference worked, the struct is then in a dynamic array on the heap, whereas the dynamic array itself is on the stack. So, you're trying to subtract a stack pointer from a heap pointer. - Jonathan M Davis
Re: A devil self reference
On Wednesday, 15 August 2018 at 21:42:11 UTC, Jonathan M Davis wrote: What are you actually trying to do? Aside from the circular reference issues, using the address of a struct like that is very risky, because if the struct is ever moved, it will change. Yeah... my functions are all ref. Or work with slices... Also, even if the circular reference worked, the struct is then in a dynamic array on the heap, whereas the dynamic array itself is on the stack. So, you're trying to subtract a stack pointer from a heap pointer. Hm... didn't thought of that. Does this matter? My current form is like that: ´´´ void main() { S.c.sarr.length = 5; S.c.sarr[2 .. 4].usefulFun; } struct Container { S[] sarr; } struct S { static Container c; size_t id() { return &this - c.sarr.ptr; } void anotherUsefulFun() { /* works on "neighbors" of this, which are only available, if c.sarr is "well-known" */ } } void usefulFun(S[] slice) { import std.stdio; writeln(slice[0].id); } ´´´ It works. After a lot of debugging and head aches, it works as I want to. But, only until I try to copy the array, as you said. I'm aware of the problem, and I worked it out so far, that on copies of the array sarr only the operations are done, which do not need the pointer stuff. Like dumping the data, for example, or querying elementary properties. Even querying for id on a array copy is ok, if I do it with another function, let's call it indexOf :) What doesn't work are the calls to "neighbor"-acting functions, but these are not needed on sarr copies. The project is almost finished, so, I'm mainly after a learn effect now. What I'm looking for, is something what would simplify my structure. So... I can think at least of two things: 1. something, where I don't need the dangerous pointer stuff. 2. something, which works well after I copy it. If the circular stuff worked, it would simplify my life a lot. I could define some constructors, for copying data between arrays, whereas the pointer stuff would maintain itself, as it would be "integrated" into the type. But ok, I see, that this is at least kind of strange...
Re: Linking a C program with D library
On Wednesday, 15 August 2018 at 06:39:50 UTC, Mike Parker wrote: String literals are implicitly convertible to const(char)* and are guaranteed to be nul-terminated like a C string, so this works: [...] Does that help? Yes, indeed. I think I possibly read about literal strings being nul-terminated somewhere but it must've slipped my mind.