Re: "Error: `TypeInfo` cannot be used with -betterC" on a CTFE function

2024-04-08 Thread Liam McGillivray via Digitalmars-d-learn
On Tuesday, 9 April 2024 at 00:02:02 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

```d
enum Value = (a, b) {
return a + b;
}(1, 2);
```

This alone should be a CTFE only function.

But if we want template parameters, we'd need to wrap it with 
the template.


```d
template Value(int a, int b) {
enum Value = () {
return a + b;
}();
}

int value = Value!(1, 2);
```

Does that help?


I had to reread this a few times to get a sense of what this is. 
I might have just got it. This is effectively a CTFE function for 
generating a constant based on the sum of two numbers, right? 
Doing `int value = Value!(1, 2);` would set `value` to 3, right?


I suppose this was a good new thing to learn, though I'm still 
quite far from being able to construct a function from another 
function using a template.


I suppose that if I wanted it to make a function from another 
function, I may be able to do it in a template using some `static 
foreach` to make arrays of function parameters, and then combine 
them together without the use of strings, instead using 
placeholders (aliases or whatever they'd be called) and maybe the 
`tupleof` function. Am I headed in the right direction (if you 
can understand my weak attempt to describe the direction I'm 
thinking of going in)?


Re: "Error: `TypeInfo` cannot be used with -betterC" on a CTFE function

2024-04-08 Thread Richard (Rikki) Andrew Cattermole via Digitalmars-d-learn



On 09/04/2024 11:42 AM, Liam McGillivray wrote:
On Monday, 8 April 2024 at 08:12:22 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

```d
template Foo(Args) {
enum Foo = () {
    return Args.init;
}();
}
```

Something like that should work instead.


I'm sorry, but I can't comprehend any of your example. What would be 
fed into `Args`? I don't understand how this works, or how I would 
use it for what I want.


You would replace it with whatever template parameters you want 
(including nothing). It's there as a place holder.


Same for the return on the closure.

But the main thing to understand is that the closure that gives the 
enum a value, that'll be CTFE only, no runtime target.


Are you saying that this is a way to guarantee that the code is 
compile-time only?


More or less.

I still understand very little of this code. I'm not experienced in D 
metaprogramming; just the function I posted above was a major 
achievement for me. I don't understand how I would use the code you gave 
in place of the function I have written and posted above.


Let's break it down.

The expression that initializes the ``func`` variable, this is a 
closure. The ``a`` and ``b`` are function parameter names (types do not 
need to be provided).


```d
alias FuncType = int function(int, int);

FuncType func = (a, b) {
return a + b;
};

int value = func(1, 2);
```

The alias is used to give a name to the function pointer type.

Next, let's combine the function pointer storage variable with the 
result with the call.


```d
int value = (a, b) {
return a + b;
}(1, 2);
```

We can swap the type ``int`` for the ``enum`` keyword, this produces a 
compile time constant that is an ``int`` that has the value 3.


```d
enum Value = (a, b) {
return a + b;
}(1, 2);
```

This alone should be a CTFE only function.

But if we want template parameters, we'd need to wrap it with the template.

```d
template Value(int a, int b) {
enum Value = () {
return a + b;
}();
}

int value = Value!(1, 2);
```

Does that help?


Re: "Error: `TypeInfo` cannot be used with -betterC" on a CTFE function

2024-04-08 Thread Liam McGillivray via Digitalmars-d-learn
On Monday, 8 April 2024 at 08:12:22 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

```d
template Foo(Args) {
enum Foo = () {
    return Args.init;
}();
}
```

Something like that should work instead.


I'm sorry, but I can't comprehend any of your example. What 
would be fed into `Args`? I don't understand how this works, 
or how I would use it for what I want.


You would replace it with whatever template parameters you want 
(including nothing). It's there as a place holder.


Same for the return on the closure.

But the main thing to understand is that the closure that gives 
the enum a value, that'll be CTFE only, no runtime target.


Are you saying that this is a way to guarantee that the code is 
compile-time only?


I still understand very little of this code. I'm not experienced 
in D metaprogramming; just the function I posted above was a 
major achievement for me. I don't understand how I would use the 
code you gave in place of the function I have written and posted 
above.


When you say that "You would replace it with whatever template 
parameters you want", are you saying that instead of doing 
`mixin(MakeStringOverload!SetWindowTitle); 
mixin(MakeStringOverload!LoadShader);` as posted above, I would 
write `mixin(Foo!(SetWindowTitle, LoadShader));`?


What does the `return Args.init;` line mean in your example? Am I 
supposed to replace this with a call to the CTFE function I had 
already written? If so, it didn't work. Making such a replacement 
resulted in the same "TypeInfo" error that I had already.


Re: Setting up CI for Dub project on Github

2024-04-08 Thread Dmitry Olshansky via Digitalmars-d-learn
On Monday, 8 April 2024 at 13:23:12 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

On 09/04/2024 1:20 AM, Dmitry Olshansky wrote:
I haven’t done any research on the subject, would be nice if 
somebody pointed me to good example of how it’s done.


—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me


In case you haven't already found:

https://github.com/dlang-community/setup-dlang


Thanks, Rikki, that should do the trick.

—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me


Re: Setting up CI for Dub project on Github

2024-04-08 Thread Richard (Rikki) Andrew Cattermole via Digitalmars-d-learn

On 09/04/2024 1:20 AM, Dmitry Olshansky wrote:
I haven’t done any research on the subject, would be nice if somebody 
pointed me to good example of how it’s done.


—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me


In case you haven't already found:

https://github.com/dlang-community/setup-dlang


Setting up CI for Dub project on Github

2024-04-08 Thread Dmitry Olshansky via Digitalmars-d-learn
I haven’t done any research on the subject, would be nice if 
somebody pointed me to good example of how it’s done.


—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me


Re: How to add a character literal to a string without ~ operator?

2024-04-08 Thread IchorDev via Digitalmars-d-learn

On Thursday, 4 April 2024 at 18:14:54 UTC, BoQsc wrote:
I'm looking for more readable standard function to add a 
**character** literal to a **string**.


Concatenate is the verb you're looking for, not add. 'Adding' a 
`char` to a `string` sounds like you want `myString[] += 
myChar;`, which wouldn't compile because `string`s are aliases of 
`immutable(char)[]`.



Pseudo example:
```
import std;
void main(){
string word = hello;
join(word, 'f', " ", "World");
writeln(word);  // output: hellof World

}

```


I'd usually use 
[`text`](https://dlang.org/phobos/std_conv.html#text). It 
automatically converts each parameter to a string and 
concatenates all of them. If you prefer format strings, there's 
[`format`](https://dlang.org/phobos/std_format.html#format).


Re: impure

2024-04-08 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Monday, 8 April 2024 at 07:53:01 UTC, Dom DiSc wrote:



On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
Try `debug unittest {...}`?


Cool. This seems to work. That's a nice workaroud for tests. 
Yay!


Nice, fyi, you can use it with statements inside function bodies 
as well. Usefull for doing logging in pure functions.




Re: "Error: `TypeInfo` cannot be used with -betterC" on a CTFE function

2024-04-08 Thread Richard (Rikki) Andrew Cattermole via Digitalmars-d-learn

On 08/04/2024 10:45 AM, Liam McGillivray wrote:
On Sunday, 7 April 2024 at 08:59:55 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

Unfortunately runtime and CTFE are the same target in the compiler.


:-(
Will this ever be changed?


A tad unlikely, it would be a rather large change architecturally to dmd.


```d
template Foo(Args) {
enum Foo = () {
    return Args.init;
}();
}
```

Something like that should work instead.


I'm sorry, but I can't comprehend any of your example. What would be fed 
into `Args`? I don't understand how this works, or how I would use it 
for what I want.


You would replace it with whatever template parameters you want 
(including nothing). It's there as a place holder.


Same for the return on the closure.

But the main thing to understand is that the closure that gives the enum 
a value, that'll be CTFE only, no runtime target.


Re: impure

2024-04-08 Thread Dom DiSc via Digitalmars-d-learn

On Monday, 8 April 2024 at 07:03:40 UTC, Alexandru Ermicioi wrote:

On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
I'm creating a library that is completely pure, but it doesn't 
compile with pure: at the top because of one impure unittest 
(which uses random to  test some things only probabilistic)!


So do I really need to declare every function pure 
individually because of a test?!?


Can we please have a @impure attribute?
And by the way also @throws and @gc?
That would make live so much easier...


Try `debug unittest {...}`?


Cool. This seems to work. That's a nice workaroud for tests. Yay!


Re: impure

2024-04-08 Thread Dom DiSc via Digitalmars-d-learn

On Sunday, 7 April 2024 at 23:32:24 UTC, MrJay wrote:
A better way to apply a attribute to an entire file is to use 
an explicit scope you can still apply this to basically the 
entire file but leave the tests out of it.


Better than an explicit impure (or pure=false) attribute?
I don't think so. It heavily uglyfies the file, as single items 
without a specific attribute are interspersed in the file. So the 
scope need to end before and start again after the affected 
function or test.


An it stops working at all if e.g. one test is impure and another 
test is @gc, because then the scopes overlap and can no more be 
contained in each other.


Really, having the counter-attributes would improve the language.


Re: impure

2024-04-08 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
I'm creating a library that is completely pure, but it doesn't 
compile with pure: at the top because of one impure unittest 
(which uses random to  test some things only probabilistic)!


So do I really need to declare every function pure individually 
because of a test?!?


Can we please have a @impure attribute?
And by the way also @throws and @gc?
That would make live so much easier...


Try `debug unittest {...}`?