Re: Phobos Unittest

2021-09-07 Thread Per Nordlöw via Digitalmars-d-learn

On Friday, 3 September 2021 at 23:39:44 UTC, Per Nordlöw wrote:
When is a phobos unittest supposed to be qualified with version 
`(StdUnittest)`? Ideally, always? I don't see that their 
current use is consistenly following a rule. If so, is the 
purpose of its presence to reduce the burden of the compiler 
when the application using phobos is compiled with -unittest? 
(edited).


For reference, see my previous attempt at making dmd more 
flexible at compiling unittests at


https://github.com/dlang/dmd/pull/6375


Re: Absence of isAllocator trait

2021-09-06 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 6 September 2021 at 15:46:52 UTC, Paul Backus wrote:

* `void allocate(size_t size)`


Should be

* `void[] allocate(size_t size)`

Thanks. Here's what I have so far

```d
enum isAllocator(T) = (is(typeof(T.allocate(size_t.init)) == 
void[]) &&

   is(typeof(T.alignment) == uint));
```


Re: Phobos Unittest

2021-09-04 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 4 September 2021 at 20:05:17 UTC, Per Nordlöw wrote:

```sh
time dmd import_std.d -o-
```


should be

```sh
time dmd -unittest import_std.d -o-
```


Re: Phobos Unittest

2021-09-04 Thread Per Nordlöw via Digitalmars-d-learn
On Saturday, 4 September 2021 at 13:12:49 UTC, Steven 
Schveighoffer wrote:
Note that lexing and parsing is extremely quick, and I wouldn't 
focus on trying to trim this out, you won't get much 
performance out of that.


-Steve


For the record, a D file containing only `import std;` type 
checks via


```sh
time dmd import_std.d -o-
```

in 0.20s whereas

```sh
time dmd import_std.d -o-
```

in 0.45s on my ThreadRipper.


Absence of isAllocator trait

2021-09-04 Thread Per Nordlöw via Digitalmars-d-learn
Is there a reason for the absence of an `isAllocator` trait under 
`std.experimental.allocator`?


Re: Phobos Unittest

2021-09-04 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 4 September 2021 at 12:40:02 UTC, Per Nordlöw wrote:
Omg. It really seems like it's motivated to do a benchmark with 
phobos unittests prefixed with


Should have been a reply to


The "never" is false, https://d.godbolt.org/z/c4oeYM7rG


Re: Phobos Unittest

2021-09-04 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 4 September 2021 at 12:40:02 UTC, Per Nordlöw wrote:
then. I can make that refactoring in my favorite choice of 
editor and see the result differ. In terms of binary size, and 
speed and memory usage of check, build and link time.


Automated that is.

If we want this, shall we format as

```d
version (StdUnittest) [QUALIFIER...] unittest
```

instead of current

```d
version (StdUnittest)
[QUALIFIER...] unittest
```

?


Re: Phobos Unittest

2021-09-04 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 4 September 2021 at 12:31:33 UTC, Dennis wrote:
On Saturday, 4 September 2021 at 09:42:46 UTC, Per Nordlöw 
wrote:

Yes, but they are lexed and parsed, right?


Right, but that's the case regardless of `version(StdUnittest)`.


Omg. It really seems like it's motivated to do a benchmark with 
phobos unittests prefixed with


version(StdUnittest)

then. I can make that refactoring in my favorite choice of editor 
and see the result differ. In terms of binary size, and speed and 
memory usage of check, build and link time.


Re: Phobos Unittest

2021-09-04 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 4 September 2021 at 12:31:33 UTC, Dennis wrote:

Right, but that's the case regardless of `version(StdUnittest)`.


I don't think so. My guess is that `version(StdUnittest)` does 
maximum parsing, maybe only lexing. How can one easily determine 
if this is the fact? Behaviour of `pragma(msg)`?


Re: Phobos Unittest

2021-09-04 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote:
As Steven Schveighoffer [pointed out][1], Phobos unittests are 
never included in user code, regardless of whether 
`StdUnittest` is used.


Yes, but they are lexed and parsed, right?


Phobos Unittest

2021-09-03 Thread Per Nordlöw via Digitalmars-d-learn
When is a phobos unittest supposed to be qualified with version 
`(StdUnittest)`? Ideally, always? I don't see that their current 
use is consistenly following a rule. If so, is the purpose of its 
presence to reduce the burden of the compiler when the 
application using phobos is compiled with -unittest? (edited).


If we were to put a `version (StdUnittest)` in front of every 
`unittest` in phobos (via an automated refactoring of course) 
would that speed building large applications or tests-suites with 
the `-unittest` flag provide they import many/all phobos 
libraries via, for instance, import `std`?


When compiling non-phobos modules with `-unittest` flag, how are 
the `unittest`-blocks in imported phobos modules processed by the 
compiler? Are they only lexed (and parsed) but nothing else?


Re: Need for std.meta.isSame over __traits(isSame)

2021-09-01 Thread Per Nordlöw via Digitalmars-d-learn

On Wednesday, 1 September 2021 at 22:51:40 UTC, Per Nordlöw wrote:

Can somebody explain the need for


Ok, `__traits(isSame)` always returns false for values.

This is very unfortunate as `std.traits.isSame` is one of the 
most used template instances in typical std.meta-programming and 
has a noticeable impact on time and space complexity now that 
AliasAssign-enabled versions of std.meta members have removed the 
need for other costly recursive template patterns.


I suggest we add a new builtin trait that exactly mimics 
std.traits.isSame or inline the calls to `isSame` in 
`std.traits.meta`. This is gonna significantly speed up functions 
in std.meta, for instance `staticIndexOf`, `EraseAll`, 
`GenericReplace`, `ReplaceAll`, `Pack`.


Need for std.meta.isSame over __traits(isSame)

2021-09-01 Thread Per Nordlöw via Digitalmars-d-learn

Can somebody explain the need for

```d
private template isSame(alias a, alias b)
{
static if (!is(typeof( && )) // at least one is an rvalue
&& __traits(compiles, { enum isSame = a == b; })) // 
c-t comparable

{
enum isSame = a == b;
}
else
{
enum isSame = __traits(isSame, a, b);
}
}
```

when there is already

```d
__traits(isSame, a, b)
```

?

Are there any cases where

```d
__traits(isSame, a, b)
```

doesn't have the same value as

```d
a == b
```

provided the static if expression above is true.


Re: Object.dup?

2021-08-31 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 30 August 2021 at 20:32:28 UTC, Adam D Ruppe wrote:
You can define one yourself of course with overrides in child 
classes to update those kinds of things. But doing it 
automatically is tricky.


Yes, thanks. I was interested in the possibility of a single 
non-member function, though.


Object.dup?

2021-08-30 Thread Per Nordlöw via Digitalmars-d-learn
Why doesn't `Object` have an auto-defined `.dup` property? It 
would be useful when dealing with, for instance, handling of 
`Throwable`'s in multi-threaded contexts.


Re: AA.values un-@safe?!

2021-07-28 Thread Per Nordlöw via Digitalmars-d-learn

On Wednesday, 28 July 2021 at 21:39:43 UTC, jfondren wrote:
I don't know, but .byValue is @safe and returns a forward 
range, so you could use `.init.byValue.array` instead.


Great point. Thanks.


AA.values un-@safe?!

2021-07-28 Thread Per Nordlöw via Digitalmars-d-learn

Why is call to `values` in, for instance,

```d
auto _ = string[string].init.values;
```

not `@safe`?


Re: Cannot call find with haystack elements having a explicit copy constructors

2021-07-15 Thread Per Nordlöw via Digitalmars-d-learn

On Thursday, 15 July 2021 at 11:08:25 UTC, Per Nordlöw wrote:

The adding of copy construtors to `Service` defined as

```d
@safe struct Service {
this(ref return scope typeof(this) rhs) {}
this(const ref return scope typeof(this) rhs) const {}
}


Using `inout` as

```d
@safe struct Service {
this(inout ref typeof(this) rhs) inout {}
}
```

works.


Re: Cannot call find with haystack elements having a explicit copy constructors

2021-07-15 Thread Per Nordlöw via Digitalmars-d-learn

On Thursday, 15 July 2021 at 11:08:25 UTC, Per Nordlöw wrote:

fails in the same way. What's wrong?


```d
@safe struct Service {
this(ref typeof(this) rhs) {}
this(const ref typeof(this) rhs) const {}
}
```

also fails. On the other hand, using a postblit as

```
@safe struct Service {
this(this) {}
}
```

passes.


Cannot call find with haystack elements having a explicit copy constructors

2021-07-15 Thread Per Nordlöw via Digitalmars-d-learn

The adding of copy construtors to `Service` defined as

```d
@safe struct Service {
this(ref return scope typeof(this) rhs) {}
this(const ref return scope typeof(this) rhs) const {}
}

@safe struct Session {
void openAndGetService(in string key) scope {
import std.algorithm.searching : find;
auto hit = _pairs.find!((x) => x.key == key)();
}
private Pair[] _pairs;
private struct Pair {
string key;
Service service;
}
}
```

makes a call to find error as

```
copy_ctor_find_fail.d(9): Error: template 
`std.algorithm.searching.find` cannot deduce function from 
argument types `!((x) => x.key == key)(Pair[])`, candidates are:

auto hit = _pairs.find!((x) => x.key == key)();
^
std/algorithm/searching.d(1559):`find(alias pred = "a == 
b", InputRange, Element)(InputRange haystack, scope Element 
needle)`
InputRange find(alias pred = "a == b", InputRange, 
Element)(InputRange haystack, scope Element needle)

^
std/algorithm/searching.d(1827):`find(alias pred, 
InputRange)(InputRange haystack)`

with `pred = __lambda2,
InputRange = Pair[]`
must satisfy the following constraint:
`   isInputRange!InputRange`
InputRange find(alias pred, InputRange)(InputRange haystack)
^
std/algorithm/searching.d(1881):`find(alias pred = "a == 
b", R1, R2)(R1 haystack, scope R2 needle)`
R1 find(alias pred = "a == b", R1, R2)(R1 haystack, scope R2 
needle)

^
std/algorithm/searching.d(2340):`find(alias pred = "a == 
b", Range, Ranges...)(Range haystack, Ranges needles)`

with `pred = __lambda2,
Range = Pair[],
Ranges = ()`
must satisfy the following constraint:
`   Ranges.length > 1`
Tuple!(Range, size_t) find(alias pred = "a == b", Range, 
Ranges...)

^
std/algorithm/searching.d(2455):`find(RandomAccessRange, 
alias pred, InputRange)(RandomAccessRange haystack, scope 
BoyerMooreFinder!(pred, InputRange) needle)`

RandomAccessRange find(RandomAccessRange, alias pred, InputRange)(
^```
Using

```d
auto hit = _pairs.find!((scope const ref x) => x.key == key)();
```

fails in the same way. What's wrong?



Improved diagnostics for mismatched template constraints

2021-05-12 Thread Per Nordlöw via Digitalmars-d-learn

Given

```d
import std.range.primitives : isInputRange;

enum isDumb(Args...) = (Args.length == 2 && Args.length == 3);

void f(Args...)(Args args)
if (isDumb!(Args))
{
}

void g(Arg)(Arg arg)
if (isInputRange!(Arg))
{
}

@safe pure unittest
{
f(2, 3);
g(2);
}
```

`dmd` diagnoses the first level as

```
/home/per/f.d(18,6): Error: template `f.f` cannot deduce function 
from argument types `!()(int, int)`, candidates are:

/home/per/f.d(6,6):`f(Args...)(Args args)`
  with `Args = (int, int)`
  must satisfy the following constraint:
`   isDumb!Args`
/home/per/f.d(19,6): Error: template `f.g` cannot deduce function 
from argument types `!()(int)`, candidates are:

/home/per/f.d(11,6):`g(Arg)(Arg arg)`
  with `Arg = int`
  must satisfy the following constraint:
`   isInputRange!Arg
```

I'm certain I've seen dmd be able to diagnose which 
sub-expression of `isDumb` and `isInputRange` that evaluated to 
false. Did I just dream this or is there a way? If there is a way 
does this improvement still reside in a dmd PR?


Re: What does @nogc do to a class?

2021-05-06 Thread Per Nordlöw via Digitalmars-d-learn

On Thursday, 6 May 2021 at 01:04:02 UTC, Jack wrote:
Does it allocate the object rather on stack, like auto scope a 
= new A or what?


Further note that

auto scope a = new A;

can be written shorter as

scope a = new A;


Re: Shared with synchronized

2021-04-19 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 4 March 2019 at 00:07:39 UTC, r-const-dev wrote:
I'm trying to implement a thread safe class, guarding data 
access with synchronized and atomicOp.


To get more help with memory safety checking from the compiler, 
please instead use `@safe` as


```d
import std.typecons : Nullable;

@safe class SharedObject {
private Nullable!int sharedValue;
private int changeCount = 0;
synchronized void modifyValue(int newValue) @trusted {
(cast(SharedObject)this).unsafeModifyValue(newValue);
}
private void unsafeModifyValue(int newValue) {
sharedValue = newValue;
++changeCount;
}
}

@safe void main()
{
shared SharedObject data = new shared SharedObject();
data.modifyValue(3);
}
```


Re: GC memory fragmentation

2021-04-12 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 12 April 2021 at 20:50:49 UTC, Per Nordlöw wrote:

more aggressive collections when nearing it.


What is a more aggressive collection compared to a normal 
collection? Unfortunately we still have no move support in D's GC 
because of its impreciseness.


Re: GC memory fragmentation

2021-04-12 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 12 April 2021 at 20:50:49 UTC, Per Nordlöw wrote:

I'm surprised there is no such functionality available.
It doesn't sound to me like it's that difficult to implement.


Afaict, we're looking for a way to call `GC.collect()` when 
`GC.Status.usedSize` [1] reaches a certain threshold.


I wonder how other GC-backed languages handle this.

[1] https://dlang.org/phobos/core_memory.html#.GC.Stats.usedSize


Re: GC memory fragmentation

2021-04-12 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 12 April 2021 at 07:03:02 UTC, Sebastiaan Koppe wrote:
On side-note, it would also be good if the GC can be aware of 
the max memory it is allotted so that it knows it needs to do 
more aggressive collections when nearing it.


I'm surprised there is no such functionality available.
It doesn't sound to me like it's that difficult to implement.


Error when running dmd compilable tests

2021-04-11 Thread Per Nordlöw via Digitalmars-d-learn

Inside dmd source tree, under sub-directory test, I do

./run.d compilable/

. This errors as

```
 ... compilable/json.d  -d -preview=dip1000 -o- -X 
-Xf/home/per/Work/dmd/test/test_results/compilable/json.out  
-fPIC ()==

Test 'compilable/json.d' failed. The logged output:
Executing post-test script: tools/postscript.sh 
compilable/extra-files/json-postscript.sh compilable json 
/home/per/Work/dmd/test/test_results/compilable/json.d.out0

tools/postscript.sh: line 18: /home/per/Work/dmd/test/tools
/home/per/Work/dmd/test/tools/exported_vars.sh: No such file or 
directory
/home/per/Work/dmd/generated/linux/release/64/dmd -conf= -m64 
-Icompilable -d -preview=dip1000 -o- -X 
-Xf/home/per/Work/dmd/test/test_results/compilable/json.out  
-fPIC  -od/home/per/Work/dmd/test/test_results/compilable 
-of/home/per/Work/dmd/test/test_results/compilable/json_0.o  -c 
compilable/json.d


==
Test 'compilable/json.d' failed: Expected rc == 0, but exited 
with rc == 1



TARGET FAILED: compilable/json.d
 ... compilable/ddoc8.d -D 
-Dd/home/per/Work/dmd/test/test_results/compilable -o-  -fPIC 
()==

```

What's wrong?


Fastest Way to Append Multiple Elements to an Array

2021-04-10 Thread Per Nordlöw via Digitalmars-d-learn

https://forum.dlang.org/post/rkxnfxsjvkffxufok...@forum.dlang.org

On Thursday, 1 January 2015 at 19:18:34 UTC, Nordlöw wrote:
Do we really need Append and Prepend (along with append and 
prepend) here? Doesn't [cC]hain already fulfill the needs of a 
lazy range in this case inplace of Append?


Is there still a place for `append` in Phobos?

What about reusing `chain(args)` for realizing 
append(Args...)(lhs, args)?


Re: Is dlang.slack.com down?

2021-04-05 Thread Per Nordlöw via Digitalmars-d-learn

On Sunday, 4 April 2021 at 11:48:37 UTC, Imperatorn wrote:

On Sunday, 4 April 2021 at 11:12:36 UTC, Per Nordlöw wrote:
Trying to access https://dlang.slack.com/ hangs for minutes on 
my machine.


I'm only using the app, same thing there for you? 樂


I was trying the desktop version. Works now. Seems to have been 
temporary.


Is dlang.slack.com down?

2021-04-04 Thread Per Nordlöw via Digitalmars-d-learn
Trying to access https://dlang.slack.com/ hangs for minutes on my 
machine.


Re: Using onOutOfMemoryError in C wrappers

2021-03-24 Thread Per Nordlöw via Digitalmars-d-learn

On Wednesday, 24 March 2021 at 10:25:21 UTC, Basile B. wrote:
In now way. But in your question you mentioned @nogc nothrow 
and not @safe and pure.


Ok, thanks.

Note that core.exception.onOutOfMemoryError is already qualified 
as @nogc nothrow pure @trusted.


Re: Using onOutOfMemoryError in C wrappers

2021-03-24 Thread Per Nordlöw via Digitalmars-d-learn

On Wednesday, 24 March 2021 at 08:31:19 UTC, Basile B. wrote:
There are several ways to do that. In addition to 
onOutOfMemoryError, you can use a static instance


  void v() @nogc nothrow
  {
__gshared oom = new OutOfMemoryError();
auto X* = X_create();
if (X is null)
throw oom;
  }


How is that better than

void v() @nogc nothrow
{
auto X* = X_create();
if (X is null)
onOutOfMemoryError();
}

considering the fact that accessing `__gshared` state is neither 
`@safe` nor `pure`? Which, in turn, makes `v()` unconditionally 
unsafe and unpure regardless of safety and purity of `X_create()`.


Using onOutOfMemoryError in C wrappers

2021-03-24 Thread Per Nordlöw via Digitalmars-d-learn
When wrapping C code that tries to allocate memory resources via 
functions such as


X* X_create();

should one call `onOutOfMemoryError();` upon null return?

Making more D wrappers `nothrow @nogc`.


Re: Implicit conversion of unique chars[] to string

2021-03-23 Thread Per Nordlöw via Digitalmars-d-learn
On Tuesday, 23 March 2021 at 01:07:15 UTC, Steven Schveighoffer 
wrote:
And the answer is complex. You can't accept a const range, 
because they don't work. The only way to have purity infer 
uniqueness is to accept paramters that the result could not 
have come from. Usually this means accepting const and 
returning mutable.


How do we want this to work with and without the presence of 
`return` qualified parameters?


Re: Implicit conversion of unique chars[] to string

2021-03-23 Thread Per Nordlöw via Digitalmars-d-learn
On Tuesday, 23 March 2021 at 01:07:15 UTC, Steven Schveighoffer 
wrote:

const(char)[] x = "foo";
string chained = chainPath(x, "bar").array;


that calls the template overload

ForeachType!Range[] array(Range)(Range r)
if (isIterable!Range && !isAutodecodableString!Range && 
!isInfinite!Range)


should be able to implicitly convert to string because the .array 
expression is inferred `pure`. Or is the compiler pessimistically 
assuming that the slice returned from the .array call may reside 
from a reference reachable from the range parameter `r`?


See for instance

@safe pure unittest
{
import std.path : chainPath;
import std.array : array;
const(char)[] x1 = "foo";
const string x2 = "bar";
auto y1 = chainPath(x1, x2).array;
pragma(msg, __FILE__, "(", __LINE__, ",1): Debug: ", 
typeof(y1));

auto y2 = chainPath(x2, x1).array;
pragma(msg, __FILE__, "(", __LINE__, ",1): Debug: ", 
typeof(y2));

}

printing

/home/per/f.d(8,1): Debug: const(char)[]
/home/per/f.d(10,1): Debug: const(char)[]


Re: Implicit conversion of unique chars[] to string

2021-03-22 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 22 March 2021 at 20:38:36 UTC, Per Nordlöw wrote:

chainPath(...).array


To clarify, for instance, given

  string s;
  const(char)[] c;

all the calls

  chainPath(s, s).array
  chainPath(c, c).array
  chainPath(s, c).array
  chainPath(c, s).array

return a value of type const(char)[].


Implicit conversion of unique chars[] to string

2021-03-22 Thread Per Nordlöw via Digitalmars-d-learn

Am I the only one being annoyed by the fact that

chainPath(...).array

doesn't implicit convert to string despite the array returned 
from .array is allocated by the GC.


Yes, I know that I should do

chainPath(...).array.assumeUnique

but the uniqueness of .array (and in turn implicit conversion to 
immutable) should be inferred by the compiler.


Inference could happen in the same compiler pass that checks 
(will infer) scope qualifiers.


Are there plans for making this happen?

Is having a @unique qualifier motivated for the sake of compiler 
performance to avoid the for need transitive inference across 
function calls?


Re: Make foreach element optional

2021-03-16 Thread Per Nordlöw via Digitalmars-d-learn

On Tuesday, 16 March 2021 at 13:31:34 UTC, Imperatorn wrote:

foreach(0..n) could work. Why though.


When performing a side-effect n times.


Make foreach element optional

2021-03-16 Thread Per Nordlöw via Digitalmars-d-learn

I find myself writing

foreach (_; 0 .. n)
doSomething(); // no using the variable `_`

.

What about relaxing the syntax to allow

foreach (; 0 .. n)

and/or

foreach (0 .. n)

?

Thereby making the `ForeachTypeList` of `AggregateForeach` in the 
grammar rule [1] optional.


[1] https://dlang.org/spec/statement.html#foreach-statement


Re: GC.addRange in pure function

2021-02-12 Thread Per Nordlöw via Digitalmars-d-learn

On Tuesday, 9 February 2021 at 03:05:10 UTC, frame wrote:

On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling 
GC.addRange or GC.removeRange isn't allowed?


Would making

`new T[]` inject a call to `GC.addRange` based on `T` (and maybe 
also T's attributes)


be a step forward?


Re: Type of string literal concatenated with non-immutable char array

2021-02-01 Thread Per Nordlöw via Digitalmars-d-learn
On Monday, 1 February 2021 at 15:47:33 UTC, Steven Schveighoffer 
wrote:
"Concatenation always creates a copy of its operands, even if 
one of the operands is a 0 length array"


Btw, does

x ~ y ~ z ~ ...

result in a single allocation?


Re: Type of string literal concatenated with non-immutable char array

2021-02-01 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 1 February 2021 at 16:30:31 UTC, Per Nordlöw wrote:

Btw, does

x ~ y ~ z ~ ...

result in a single allocation?


Provided all the operands has a `length` property.


Re: Type of string literal concatenated with non-immutable char array

2021-02-01 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 1 February 2021 at 10:27:29 UTC, Jacob Carlborg wrote:

Why isn't

"Name " ~ name ~ " could not be found"

implicitly convertible to `string`?


Because if you have arrays of reference types, it's possible to 
change an element of the mutable array, which will affect the 
immutable array, those breaking the immutability. Example:


I still don't understand why that restriction applies to arrays 
of values types (such as `char`). Having this limitation makes my 
code example more bloated or less efficient memorywise; I either 
have to define two separate ctors or force an .idup at the site 
of the exception construction.


Re: Why are multiple instances of the single enum created?

2021-02-01 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 1 February 2021 at 10:24:59 UTC, Mike Parker wrote:
There is no "extra" instance because there's no single instance 
of an enum value. They have no address. When you use one, it's 
just as if you were writing the literal instead of the enum 
name. In other words:


enum ea = [1, 2, 3];
auto a0 = ea;
auto a1 = ea;

is identical to this:

auto a0 = [1, 2, 3];
auto a1 = [1, 2, 3];


Ok, so then my follow-up question becomes, does the right hand 
sides of these two assignment share the same AST node? If not, 
why?


Re: Why are multiple instances of the single enum created?

2021-02-01 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 1 February 2021 at 11:37:49 UTC, Per Nordlöw wrote:
Ok, so then my follow-up question becomes, does the right hand 
sides of these two assignment share the same AST node? If not, 
why?


Because such a shared AST node could be potentially mutated in 
different ways in different contexts during its passes?


Re: Why are multiple instances of the single enum created?

2021-02-01 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 1 February 2021 at 09:52:07 UTC, Jacob Carlborg wrote:
If you don't want a new instance, then don't use `enum`. Use 
`immutable` instead.


Agreed. My question is why does an `enum` require an extra 
instance from a compiler architecture point of view? Do all 
compilers handle compile-time enum instances in that way?


Why are multiple instances of the single enum created?

2021-02-01 Thread Per Nordlöw via Digitalmars-d-learn

An enum only exists at compile-time, and does not occupy any
space. Each time it's referenced, a new instance of the value
is created. Why is that? Seems like a waste of resources to the 
compiler.


Type of string literal concatenated with non-immutable char array

2021-01-31 Thread Per Nordlöw via Digitalmars-d-learn

Given

char x[];

why is

typeof("a" ~ x)

`char[]` when

typeof("a" ~ x.idup)

is

`string`?

My case is

class NameLookupException : Exception
{
this(string name) {
super("Name " ~ name ~ " could not be found");
}
this(scope const(char)[] name) {
super("Name " ~ name.idup ~ " could not be found");
}
}

where I instead would like to only need

class NameLookupException : Exception
{
this(scope const(char)[] name) {
super("Name " ~ name ~ " could not be found");
}
}

Why isn't

"Name " ~ name ~ " could not be found"

implicitly convertible to `string`?

Would

class NameLookupException : Exception
{
this(scope const(char)[] name) @trusted {
super("Name " ~ cast(string)name ~ " could not be found");
}
}

be ok?


Re: Convert double to long if lossless

2021-01-19 Thread Per Nordlöw via Digitalmars-d-learn

On Tuesday, 19 January 2021 at 21:04:51 UTC, kdevel wrote:
And then? I mean: What do you want to do with the long what 
could not

be done with the double in the first place?


Motivated question.

We want to propagate to our system locally that a double received 
from a network communication actually is an integer and should be 
stored and treated as such in an algebraic type.


Re: Convert double to long if lossless

2021-01-19 Thread Per Nordlöw via Digitalmars-d-learn

On Tuesday, 19 January 2021 at 16:14:17 UTC, drug wrote:

   https://dlang.org/phobos/std_bitmanip.html#FloatRep


Doesn't this pattern already cover all possible cases of `value` 
needed?


void f(double value)
{
auto lvalue = cast(long)value;
if (lvalue == value) // `value` lacks fraction and in range 
[long.min .. long.max]

{
// use long lvalue
return;
}
// use double value
}



Re: Convert double to long if lossless

2021-01-19 Thread Per Nordlöw via Digitalmars-d-learn

On Tuesday, 19 January 2021 at 17:03:53 UTC, Ali Çehreli wrote:

I think it would be a useful improvement.


Indeed. Maybe Ilya could help out adding this to dmd.


Re: Convert double to long if lossless

2021-01-19 Thread Per Nordlöw via Digitalmars-d-learn
On Tuesday, 19 January 2021 at 13:36:58 UTC, Steven Schveighoffer 
wrote:

Use a cast instead.

const lvalue = cast(long)value;


Ahh, good point.

Followd by a compare of the original value I presume.


Convert double to long if lossless

2021-01-19 Thread Per Nordlöw via Digitalmars-d-learn
I want to convert a double to a long if conversion is lossless 
(without fractional part, non-nan, non-inf, within long-range, 
etc).


I currently have

void foo()
{
const double value = 10.1;
try
{
import std.conv : to;
const lvalue = value.to!long;
if (lvalue == value)
{
writeln("lvalue:", lvalue);
return;
}
}
catch (Exception e) {}
writeln("value:", value);
}

Can this be improved?

For instance how do I check if a float/double/real has a 
fractional part and avoid entering try-catch for those cases?


Re: Recursively defined matcher function

2021-01-03 Thread Per Nordlöw via Digitalmars-d-learn

On Sunday, 3 January 2021 at 18:26:44 UTC, Per Nordlöw wrote:


alias Matcher = Match function(Matcher[] matchers...);

but it errors as

recursive alias declaration


Preferrably I wanted a non-templated definition.


Recursively defined matcher function

2021-01-03 Thread Per Nordlöw via Digitalmars-d-learn
How can I define a function type `Matcher` that takes an array of 
`Matcher`s and returns an instance of a `struct Match` defined as


struct Match
{
@safe pure nothrow @nogc:
static Match zero()
{
return typeof(return)(0);
}
static Match none()
{
return typeof(return)(_length.max);
}
/// Match length in number of UTF-8 chars or 0 if empty.
@property uint length()
{
return _length;
}
bool opCast(U : bool)() const
{
return _length != _length.max;
}
this(size_t length)
{
assert(length <= _length.max);
this._length = cast(typeof(_length))length;
}
const uint _length;// length == uint.max is 
no match

}

I've tried

alias Matcher = Match function(Matcher[] matchers...);

but it errors as

recursive alias declaration


Re: Git-repo-root relative path

2020-11-22 Thread Per Nordlöw via Digitalmars-d-learn
On Wednesday, 18 November 2020 at 23:43:15 UTC, Petar Kirov 
[ZombineDev] wrote:

https://gist.github.com/PetarKirov/b4c8b64e7fc9bb7391901bcb541ddf3a


Thanks a lot!


Re: Git-repo-root relative path

2020-11-16 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 16 November 2020 at 10:21:27 UTC, Per Nordlöw wrote:

Which DUB packages do you prefer?


https://code.dlang.org/packages/dlibgit seems good. But that 
requires `libgit` to be installed. It would be nice to have a 
fallback to calling `git`.


Git-repo-root relative path

2020-11-16 Thread Per Nordlöw via Digitalmars-d-learn
I need a function that gets the relative path of a file in a 
Git-repo and preferrably also its status.


Either via an external call to `git` or optionally via `libgit` 
(if available).


Which DUB packages do you prefer?


Re: DMD: invalid UTF character `\U0000d800`

2020-11-12 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 9 November 2020 at 16:39:49 UTC, Boris Carvajal wrote:

There's also:

dchar(0xd8000)


Thanks


Re: Missing stacktrace on memory allocation failure

2020-11-12 Thread Per Nordlöw via Digitalmars-d-learn

On Thursday, 12 November 2020 at 09:22:10 UTC, Per Nordlöw wrote:

Why don't I get a stack trace on Memory allocation exceptions?


Is it because the stack may be corrupted?


Missing stacktrace on memory allocation failure

2020-11-12 Thread Per Nordlöw via Digitalmars-d-learn

Why don't I get a stack trace on Memory allocation exceptions?

In my case I only get:

src/core/exception.d(647): [unittest] Memory allocation failed
core.exception.OutOfMemoryError@src/core/exception.d(647): Memory 
allocation failed




Re: Unicode Regular Expressions

2020-11-10 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 9 November 2020 at 17:06:50 UTC, H. S. Teoh wrote:

I'm pretty sure std.regex already supports Unicode regexes.


Yep [1].

Thanks

[1] 
https://dlang.org/phobos/std_regex.html#Syntax%20and%20general%20information


Unicode Regular Expressions

2020-11-09 Thread Per Nordlöw via Digitalmars-d-learn
Is there any library that can deal with decoding and generating 
character matchers for Unicode regular expression described at


https://www.regular-expressions.info/unicode.html


Re: DMD: invalid UTF character `\U0000d800`

2020-11-08 Thread Per Nordlöw via Digitalmars-d-learn

On Sunday, 8 November 2020 at 10:47:34 UTC, Per Nordlöw wrote:

cast(dchar)0xd8000


To clarify,

enum dch1 = cast(dchar)0xa0a0;
enum dch2 = '\ua0a0';
assert(dch1 == dch2);

works. Can I use the first-variant if I want to postpone these 
encoding questions for now?


Re: DMD: invalid UTF character `\U0000d800`

2020-11-08 Thread Per Nordlöw via Digitalmars-d-learn
On Saturday, 7 November 2020 at 17:49:54 UTC, Jacob Carlborg 
wrote:

[1] https://en.wikipedia.org/wiki/UTF-16#U+D800_to_U+DFFF


Thanks!

I'm only using these UTF characters to create ranges that source 
code characters as checked against during parsing. Therefore I 
would like to just convert these to a `dchar` for now using a 
`cast`. Can I just do, for instance,


cast(dchar)0xd8000

for

`\Ud800`

to accomplish this?


DMD: invalid UTF character `\U0000d800`

2020-11-07 Thread Per Nordlöw via Digitalmars-d-learn
I'm writing a parser generator for ANTLR-grammars and have come 
across the rule


fragment Letter
: [a-zA-Z$_] // these are below 0x7F
| ~[\u-\u007F\uD800-\uDBFF] // covers all characters 
above 0x7F which are not a surrogate
| [\uD800-\uDBFF] [\uDC00-\uDFFF] // covers UTF-16 surrogate 
pairs encodings for U+1 to U+10

;

at

https://github.com/antlr/grammars-v4/blob/master/cto/CtoLexer.g4#L158

This rule is converted into

Match m__Letter()
{
return alt(alt(rng('a', 'z'), rng('A', 'Z'), ch('$'), 
ch('_')),
   not(alt(rng('\u', '\u007F'), rng('\uD800', 
'\uDBFF'))),
   seq(rng('\uD800', '\uDBFF'), rng('\uDC00', 
'\uDFFF')));

}

given suitable defs of alt, rng, seq, not.

This errors as

 CtoLexer_parser.d   665  57 error   invalid UTF 
character \Ud800
 CtoLexer_parser.d   665  67 error   invalid UTF 
character \Udbff
 CtoLexer_parser.d   666  28 error   invalid UTF 
character \Ud800
 CtoLexer_parser.d   666  38 error   invalid UTF 
character \Udbff
 CtoLexer_parser.d   666  53 error   invalid UTF 
character \Udc00
 CtoLexer_parser.d   666  63 error   invalid UTF 
character \Udfff


Doesn't DMD support these Unicodes yet?


Re: Dynamic Template-Expansion of (Token) Strings

2020-10-27 Thread Per Nordlöw via Digitalmars-d-learn

On Tuesday, 27 October 2020 at 10:46:42 UTC, Jacob Carlborg wrote:

[1] http://mustache.github.io/mustache.5.html
[2] https://code.dlang.org/packages/mustache-d


Thanks


Dynamic Template-Expansion of (Token) Strings

2020-10-27 Thread Per Nordlöw via Digitalmars-d-learn
I'm looking for elegant ways of expressing expansion of 
parameterized strings written to a file at run-time. My primary 
use case is run-time generation of D code. In the lazy case, 
something like


import std.file : write;
import std.algorithm : substitute;
const s = q{int $X = $Y;}; // templated source
foreach (part; s.substitute("$X", "x", "$Y", "42"))
write(somePath, part);

is my current best bet.


String Template Package

2020-10-26 Thread Per Nordlöw via Digitalmars-d-learn
I need a string template system for generation of parsers in D 
code to compiled in separate phase (not Pegged).


What packages is there for this?


GC-less string formatting

2020-10-20 Thread Per Nordlöw via Digitalmars-d-learn
If I want GC-free string formatting and outputting to 
stdout/stderr what packages should I prefer at code.dlang.org?


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn
On Saturday, 17 October 2020 at 13:42:46 UTC, Steven 
Schveighoffer wrote:
I think it *should* be possible to do this, if it's not 
already, just with pragmas. (i.e. pack T but not S).


Agree, a pragma, say `pragma(pack)`, to control this would be 
great to avoid the unsafe union hack.


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 17 October 2020 at 13:23:38 UTC, Adam D. Ruppe wrote:

Use a union.


Nice! Thanks!


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 17 October 2020 at 12:51:21 UTC, ag0aep6g wrote:
c does come directly after s. The padding between b and c is 
part of s. If you don't want that padding, you can use 
`align(1)` to define S without padding. But then 75% of the 
ints in an S[] will be misaligned.


I understand that. I don't want the alignment of `S` to change. I 
want the padding after `s` in `T` to be avoided and have `c` 
start at byte-offset 7. I don't see why this padding is needed in 
the case where only a single (1-element array of) `S` is stored 
as a field inside another aggregate.


Ali's code prints:

=== Memory layout of 'T' (.sizeof: 12, .alignof: 4) ===
   0: S s
   8: char c
   9: ... 3-byte PADDING


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 17 October 2020 at 12:44:44 UTC, Per Nordlöw wrote:
Can `align`s be inserted in S or/and T so that T is packed to 8 
bytes but still aligned to 8 bytes? I don't see why this 
shouldn't be the default behaviour...


I though this would do the trick but not...

struct S
{
int i;  // 4 bytes
short s;// 2 byte
bool b; // 1 byte
}
static assert(S.sizeof == 8);
static assert(S.alignof == 4);
align(4) struct T
{
align(4) S s;
align(1) char c;
}
static assert(T.alignof == 4);
// TODO: static assert(T.sizeof == 8);

T.sizeof is still 12 bytes, I want it to be 8.


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 17 October 2020 at 12:35:37 UTC, Per Nordlöw wrote:
On Friday, 16 October 2020 at 21:26:12 UTC, Steven 
Schveighoffer wrote:
To further explain this -- the padding is added so things like 
pointer arithmetic on an array work.


In my code sample above one can only access the first element 
anyhow so I don't understand why this restriction is imposed 
here.


struct S
{
int i;
bool b;
}

struct T
{
S s; // reinterpreting this as an array can only access 
this first element anyway
char c; // so why can't this be aligned directly after `s` 
without any padding?

}


So AFAICT the key question becomes:

Can `align`s be inserted in S or/and T so that T is packed to 8 
bytes but still aligned to 8 bytes? I don't see why this 
shouldn't be the default behaviour...


Re: Packing of Struct Fields

2020-10-17 Thread Per Nordlöw via Digitalmars-d-learn
On Friday, 16 October 2020 at 21:26:12 UTC, Steven Schveighoffer 
wrote:
To further explain this -- the padding is added so things like 
pointer arithmetic on an array work.


In my code sample above one can only access the first element 
anyhow so I don't understand why this restriction is imposed here.


struct S
{
int i;
bool b;
}

struct T
{
S s; // reinterpreting this as an array can only access this 
first element anyway
char c; // so why can't this be aligned directly after `s` 
without any padding?

}



Why is `Appender._data` a pointer to its `Data`-store?

2020-10-16 Thread Per Nordlöw via Digitalmars-d-learn

Why is `Appender`'s store `Data` put directly as

`private Data* _data;`

instead of

`private Data _data;`

?

Removing the pointer indirection would give better locality.

If it's about optimizing for empty `Appender`s then a `Appender*` 
should be used in those cases instead.


Packing of Struct Fields

2020-10-16 Thread Per Nordlöw via Digitalmars-d-learn
Why is `T.sizeof` 12 instead of 8 when `U.sizeof` is 8 in the 
following example?


struct S
{
int i;
bool b;
}

struct T
{
S s;
char c;
}

struct U
{
int i;
bool b;
char c;
}

?


Re: Safe to remove AA elements while iterating over it via .byKeyValue?

2020-09-28 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 28 September 2020 at 10:01:23 UTC, ikod wrote:
Is it specific to some types? What if collection supports 
stable "foreach"?


Yes it depends on how collection members (such as insert, find, 
replace, erase, etc) are implemented.


I presume we need attributes on mutating collection members that 
describes if the operation invalidates ranges or not.


It is relatively simple to implement checks for range 
invalidation at run-time. This is basically Rust-style borrow 
checking at run-time instead of compile-time.


In C++ this is called "iterator invalidation". This attributes 
are not formally defined in code but part of the documentation.


Re: Safe to remove AA elements while iterating over it via .byKeyValue?

2020-09-28 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 28 September 2020 at 07:15:27 UTC, Imperatorn wrote:

Yes, this should be a compile-time error


Spec here: 
https://dlang.org/spec/statement.html#foreach_restrictions


Re: AA with class keys compared with identity instead of opEquals

2020-09-28 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 28 September 2020 at 08:26:15 UTC, Per Nordlöw wrote:
In the case where the AA-KeyType is a class (which is 
represented as a pointer in D) I want the equality (opEquals) 
and the hashing (toHash) of the AA to compare and hash the 
pointers themselves, not the fields the classes points to.


For D-classes this is the default. For extern(C++) classes it's 
not defined. That's why I added the struct wrapper on top of an 
extern(C++) class.


Re: AA with class keys compared with identity instead of opEquals

2020-09-28 Thread Per Nordlöw via Digitalmars-d-learn
On Sunday, 27 September 2020 at 19:45:07 UTC, Ferhat Kurtulmuş 
wrote:
Sorry I did not understand what you meant. It would be better 
if you share the answer here. I found this also 
https://dlang.org/library/std/traits/key_type.html, but I dont 
know if it is related.


In the case where the AA-KeyType is a class (which is represented 
as a pointer in D) I want the equality (opEquals) and the hashing 
(toHash) of the AA to compare and hash the pointers themselves, 
not the fields the classes points to.


Re: Safe to remove AA elements while iterating over it via .byKeyValue?

2020-09-27 Thread Per Nordlöw via Digitalmars-d-learn

On Sunday, 27 September 2020 at 14:23:11 UTC, H. S. Teoh wrote:
No.  Modifying a container while iterating over it is, in 
general, a bad idea (unless the container is designed to be 
used that way, but even then, such removal is generally 
restricted), because it often leads to highly counterintuitive 
results.  In the case of AA's, removing an element may lead to 
a rehashing, which reorders elements, and your iteration may 
miss some elements or repeat some elements or terminate 
prematurely. Even without a rehashing, you may encounter 
inconsistent behaviours, like some elements going "missing".


I believe it's high time we start thinking about detecting these 
violations at compile-time. I recall it's in the spec somewhere 
so we should start a deprecation process at least for AAs.


Re: AA with class keys compared with identity instead of opEquals

2020-09-27 Thread Per Nordlöw via Digitalmars-d-learn

On Sunday, 27 September 2020 at 18:39:10 UTC, Per Nordlöw wrote:
How do I defined an AA with class as key where keys are 
compared using `is` instead of `opEquals`? Do I have to store 
the key as a `void*`?


I got a good answer at 
https://dlang.slack.com/archives/C1ZDHBB2S/p1601234030016700


Re: AA with class keys compared with identity instead of opEquals

2020-09-27 Thread Per Nordlöw via Digitalmars-d-learn
On Sunday, 27 September 2020 at 18:56:15 UTC, Ferhat Kurtulmuş 
wrote:
By looking at object.d and aaA.d of druntime, I d say you don't 
need to use void*. Object class has required infrastructure 
ready for using classes aa keys (have not tried though). Object 
class has both toHash and opEquals already implemented.


That's gonna be much slower. And I need key's to be checked for 
equivalence ,not equality.


AA with class keys compared with identity instead of opEquals

2020-09-27 Thread Per Nordlöw via Digitalmars-d-learn
How do I defined an AA with class as key where keys are compared 
using `is` instead of `opEquals`? Do I have to store the key as a 
`void*`?


Safe to remove AA elements while iterating over it via .byKeyValue?

2020-09-27 Thread Per Nordlöw via Digitalmars-d-learn
Is it safe to remove AA-elements from an `aa` I'm iterating over 
via aa.byKeyValue?


I'm currently doing this:

foreach (ref kv; aa.byKeyValue)
{
if (pred(kv.key))
aa.remove(kv.key); // ok?
}
if (aa.length == 0)
aa = null;

Is there a better way?


Re: Escape this in pure members

2020-09-23 Thread Per Nordlöw via Digitalmars-d-learn
On Wednesday, 23 September 2020 at 00:06:38 UTC, DlangUser38 
wrote:
Hmm, why would `b` have longer lifetime? Isn't the lifetime of 
`b` throughout `bar`?


The following analysis might be wrong but I think that `scope` 
as a **member** function attribute is not supposed to be used 
as that is not even documented.


Where's the other scope analysis documented?

So it would works "by default". The compiler thinks that `this` 
is a scope variable that will stop living after `bar()`.


So are you saying that this code should compile with and without 
the member being `scope`?


Also as `b` is not `ref` this is clearly a wrong diagnostic. 
There's a special case missing in the compiler.


Re: Escape this in pure members

2020-09-19 Thread Per Nordlöw via Digitalmars-d-learn
On Saturday, 19 September 2020 at 18:48:31 UTC, Jacob Carlborg 
wrote:

A nested class seems to be able to escape the `this` reference:


Ahh, thanks.

I just realized that it can escape into other parameters without 
the `scope` qualifier?


This

class Bar
{
void bar(scope Bar b) @safe pure
{
b = this;
}
}

compiles but this

class Bar
{
scope void bar(scope Bar b) @safe pure
{
b = this; // Error: scope variable `this` assigned to `b` 
with longer lifetime

}
}

fails as

foo.d(6,11): Error: scope variable `this` assigned to `b` with 
longer lifetime


Re: Escape this in pure members

2020-09-19 Thread Per Nordlöw via Digitalmars-d-learn

On Saturday, 19 September 2020 at 16:07:24 UTC, Per Nordlöw wrote:
If an aggregate member is pure but not scope when can it escape 
the `this` pointer?.


Or rather when and, if so, how can the member allow its `this` 
pointer to escape?


It seems to me like the `scope` qualifier is no effect in this 
case.


Escape this in pure members

2020-09-19 Thread Per Nordlöw via Digitalmars-d-learn
If an aggregate member is pure but not scope when can it escape 
the `this` pointer?.


Only via return?

In the struct and class case?


Re: Can a call to pragma(msg, __FILE__, ...) be mixin templatized?

2020-08-18 Thread Per Nordlöw via Digitalmars-d-learn

On Tuesday, 18 August 2020 at 08:03:04 UTC, Per Nordlöw wrote:
Forgot to mention that I want to support variadic arguments to 
`ctLog` similar to what is done with


And these arguments should be of any template argument kind, not 
only a compile-time string.


Re: Can a call to pragma(msg, __FILE__, ...) be mixin templatized?

2020-08-18 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 17 August 2020 at 22:37:12 UTC, Simen Kjærås wrote:
mixin template ctLog(string msg, string file = __FILE__, size_t 
line = __LINE__) {

pragma(msg, file, "(", line, "): ", msg);
}


Thanks.

Forgot to mention that I want to support variadic arguments to 
`ctLog` similar to what is done with


void dbg(Args...)(Args args,
  const string file = __FILE_FULL_PATH__,
  const uint line = __LINE__,
  const string fun = __FUNCTION__) @safe pure 
nothrow @nogc

{
import std.stdio : stderr, writeln;
try
debug stderr.writeln(file, "(", line, ",1):", " Debug: 
\"", args, "\"");

catch (Exception) { }
}

Is this possible?


Can a call to pragma(msg, __FILE__, ...) be mixin templatized?

2020-08-17 Thread Per Nordlöw via Digitalmars-d-learn

I'm using

pragma(msg, __FILE__, "(", __LINE__, ",1): Debug: ", "A 
useful debug message");


to print compile-time information formatted as standard compiler 
diagnostics.


These are picked up by Emacs Flycheck and overlayed in the editor 
and listen in the *Flycheck errors* buffer. Very convenient. When 
I want to get the type of something at compile-time.


In order to not having to repeat oneself I'm now looking for a 
way to extract this into a `mixin template`. Is this possible 
somehow and still preserve the instantiation site values of 
`__FILE__` and `__LINE__`?


Re: LDC cross-module-inlining

2020-08-10 Thread Per Nordlöw via Digitalmars-d-learn

On Monday, 10 August 2020 at 05:54:14 UTC, Daniel Kozak wrote:
I am not sure but last time I checked ldc does not do cross 
module inlinig by default, and LTO only help if your 
ldc(druntime+phobos) are built with enabled LTO[1]


[1] 
https://github.com/ldc-developers/ldc/issues/2182#issuecomment-343166633


Are the official LDC-releases builtin with or without LTO?


Re: LDC cross-module-inlining

2020-08-09 Thread Per Nordlöw via Digitalmars-d-learn

On Sunday, 9 August 2020 at 22:45:16 UTC, claptrap wrote:
I'm not 100% sure but I think LDC did cross module inlining by 
default at some point, then I updated the compiler and had to 
add the LTO thing. I think there is an option to enable just 
cross module inlining, but if you want speed you'll probably 
want to have LTO enabled anyway?


Yes, I do. Thanks.


LDC cross-module-inlining

2020-08-09 Thread Per Nordlöw via Digitalmars-d-learn
Is cross-module-inlining enabled by default in LDC when compiling 
in release mode or do I have to use explicitly flag for it? I 
can't find any such flag from the output of neither


ldc2 -h

nor

ldmd2 -h

.

Johan Engelen mentioned this, then experimental, flag in his 
DConf talk from 2017 [1]


[1] https://www.youtube.com/watch?v=IZY67TBZ0V4


Re: I just discovered an alternative use of the `in`-operator

2020-08-09 Thread Per Nordlöw via Digitalmars-d-learn

On Thursday, 6 August 2020 at 22:24:43 UTC, Paul Backus wrote:

[1] https://dlang.org/spec/expression.html#is_expression


Thanks


Re: dpldocs not update

2020-08-08 Thread Per Nordlöw via Digitalmars-d-learn

On Friday, 7 August 2020 at 23:58:03 UTC, Adam D. Ruppe wrote:
Maybe someday we can link in dub's update to click that button 
for you but for the foreseeable future you need to hit it 
yourself to update the docs.


Got it. Thanks a lot for now, anyway.


dpldocs not update

2020-08-07 Thread Per Nordlöw via Digitalmars-d-learn
I've pushed a new tag several times now and triggered manual 
update of my


https://code.dlang.org/packages/phobos-next

but the docs at

https://phobos-next.dpldocs.info/index.html

aren't updated. For instance the file

https://github.com/nordlow/phobos-next/blob/master/src/nxt/open_hashmap.d

cannot be found in the listing at

https://phobos-next.dpldocs.info/nxt.html

What's wrong?


  1   2   3   4   >