On Sunday, 11 September 2022 at 02:14:51 UTC, zjh wrote:
On Saturday, 10 September 2022 at 22:07:32 UTC, Ali Çehreli
wrote:
On 9/10/22 13:04, Daniel Donnell wrote:
> https://dlang.org/spec/cpp_interface.html
At DConf, Manu indicated that that page is outdated and that
D's C++ support is
As you may already know if you want to move a file or rename a
folder in VisualD, you can't simply do it. I've even had to edit
the project file with Notepad++ in order to repair it.
So, I'm humbly asking how can we fix this? I'm considering doing
something in C++ which I'd rather not
On Tuesday, 13 September 2022 at 01:46:14 UTC, Paul Backus wrote:
On Tuesday, 13 September 2022 at 00:57:58 UTC, Kyle Ingraham
wrote:
I am writing a library where I would like to be able to store
instances of a type of class to an associative array for later
usage. Each class stored has to
On Tuesday, 13 September 2022 at 00:57:58 UTC, Kyle Ingraham
wrote:
I am writing a library where I would like to be able to store
instances of a type of class to an associative array for later
usage. Each class stored has to implement a function as part of
the required interface. The argument
I am writing a library where I would like to be able to store
instances of a type of class to an associative array for later
usage. Each class stored has to implement a function as part of
the required interface. The argument given is always the same
type but the return value should be
On Mon, Sep 12, 2022 at 02:29:58PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[...]
> If your intent is to *enforce* pure functions only, then that's what
> you do. If your intent instead is to ensure that given proper
> parameters, the function will be pure, then the answer is
On 9/12/22 11:29, Steven Schveighoffer wrote:
> So you are thinking about this the wrong way I believe.
Clearly.
> When you put `pure` on a template function, you are saying "only
> instantiations where this function can be pure are allowed".
Makes sense. I was trying to put as many
On 9/12/22 1:08 PM, Ali Çehreli wrote:
On 9/12/22 09:48, H. S. Teoh wrote:
>> @nogc nothrow pure @safe
>> unittest
>> {
>> // ...
>> }
>>
>> No, it isn't because unless my unittest code is impure, I can't catch
>> my incorrect 'pure' etc. on my member functions.
> [...]
>
> Sure
On 9/12/22 10:29, H. S. Teoh wrote:
write a unittest where you instantiate Foo with a
deliberately-impure type
Yes. A current on-topic thread on the difficulties of covering all
corner cases:
https://forum.dlang.org/thread/dmnfdqiplbldxkecp...@forum.dlang.org
Ali
If I have a template that accepts tokenized code to build
something, it will create the exact debug symbol with this
argument supplied which makes the symbols hard to read and/or
waste of memory.
Is there any way to truncate or transform it like that?
```
app.fun!"writeln(\"Hello, World\");"
On Mon, Sep 12, 2022 at 10:08:29AM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
[...]
> What I meant was
>
> - if I put 'pure' etc. on my templatized code,
>
> - and then tested with a 'pure' unittest,
>
> I wouldn't know that the gratuitous use of my 'pure' on the member
> function was
On 9/12/22 09:48, H. S. Teoh wrote:
>> @nogc nothrow pure @safe
>> unittest
>> {
>> // ...
>> }
>>
>> No, it isn't because unless my unittest code is impure, I can't catch
>> my incorrect 'pure' etc. on my member functions.
> [...]
>
> Sure you can. The `pure unittest` code obviously must
On Sunday, 11 September 2022 at 00:56:39 UTC, Adam D Ruppe wrote:
On Sunday, 11 September 2022 at 00:32:18 UTC, Kyle Ingraham
wrote:
I can't use default parameters because I want to be able to
call the delegate with arguments extracted from a URL path at
runtime
Some kind of wrapper might
On Mon, Sep 12, 2022 at 09:14:42AM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
[...]
> struct Foo(R) {
> R r;
> int i;
>
> bool empty() @nogc nothrow pure @safe scope {
> return r.empty;
> }
>
> auto front() @nogc nothrow pure @safe scope {
> return
On 9/12/22 12:14 PM, Ali Çehreli wrote:
What are best practices here?
attributes such as `pure`, `@nogc`, `nothrow`, `@safe` should all be
left to inference. Either the function can do those attributes, or it
cannot.
attributes such as `const` or `inout` are different -- these are *not*
On Monday, 12 September 2022 at 16:14:42 UTC, Ali Çehreli wrote:
Is this accurate: Because Foo is a template, it should not put
any attribute on member functions? Or only member functions
that use a member that depends on a template parameter? And
non-members that are templates?
Yes. Except
The following range Foo is trying to be helpful by adding as many
attributes as it can ('const' is missing because ranges cannot be
'const' because at least popFront() needs to be mutable):
import std.algorithm;
struct Foo(R) {
R r;
int i;
bool empty() @nogc nothrow pure @safe
Pretty new video from ContextFreeCode covers interop with C++
D also mentioned there :)
https://youtu.be/RdypYCxhWtw
18 matches
Mail list logo
