On Wednesday, 25 August 2021 at 22:57:23 UTC, jfondren wrote:
Contrast:
[...]
```d
void main() {
import std.stdio;
uint TestVar = 5;
string mxnWrite_Size_t(string VarName)() {
static if (typeof(mixin(VarName)).stringof == "uint") {
return `write("` ~ VarName ~
On Wednesday, 25 August 2021 at 22:52:23 UTC, DLearner wrote:
On Wednesday, 25 August 2021 at 22:33:00 UTC, H. S. Teoh wrote:
[...}
I think what you meant to write is:
static if (typeof(mixin(VarName)).stringof == "uint") {
You want the type of the variable named by VarName, not the
On Wednesday, 25 August 2021 at 22:33:00 UTC, H. S. Teoh wrote:
[...}
I think what you meant to write is:
static if (typeof(mixin(VarName)).stringof == "uint") {
You want the type of the variable named by VarName, not the
type of VarName.
T
I understand your reasoning, but:
```
On Wed, Aug 25, 2021 at 10:16:39PM +, DLearner via Digitalmars-d-learn
wrote:
> Please see below:
> ```
> void main() {
>import std.stdio;
>
>uint TestVar = 5;
>
>string mxnWrite_Size_t(string VarName) {
^^
Obviously, VarName is a string.
Please see below:
```
void main() {
import std.stdio;
uint TestVar = 5;
string mxnWrite_Size_t(string VarName) {
static if (typeof(VarName).stringof == "uint") {
return `write("` ~ VarName ~ `");`;
} else {
return `writeln("Apparently TestVar not a
On Wed, Aug 25, 2021 at 04:46:54PM +, Joseph Rushton Wakeling via
Digitalmars-d-learn wrote:
> On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven Schveighoffer wrote:
> > structs still provide a mechanism (postblit/copy ctor) to properly
> > save a forward range when copying, even if the
On Wednesday, 25 August 2021 at 17:01:54 UTC, Steven
Schveighoffer wrote:
In a world where copyability means it's a forward range? Yes.
We aren't in that world, it's a hypothetical "if we could go
back and redesign".
OK, that makes sense.
Technically this is true. In practice, it rarely
On 8/25/21 12:46 PM, Joseph Rushton Wakeling wrote:
On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven Schveighoffer wrote:
structs still provide a mechanism (postblit/copy ctor) to properly
save a forward range when copying, even if the guts need copying
(unlike classes). In general, I
On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven
Schveighoffer wrote:
structs still provide a mechanism (postblit/copy ctor) to
properly save a forward range when copying, even if the guts
need copying (unlike classes). In general, I think it was a
mistake to use `.save` as the mechanism,
On Wednesday, 25 August 2021 at 15:30:57 UTC, Steven
Schveighoffer wrote:
[...]
Another approach is to let the compiler deal with the error
handling and not muddy your return type. Swift does something
similar, where it rewrites the throw/catch into a standard
return and doesn't do actual
On 8/25/21 10:58 AM, WebFreak001 wrote:
Hm I'm not quite seeing how the error handler is related to an "Expected
type interface" that the compiler could expect.
This would be without compiler changes.
Currently with exceptions the scope things are implemented using
try-catch-finally, this
On Wednesday, 25 August 2021 at 14:42:07 UTC, Steven
Schveighoffer wrote:
I think it's possible to work with some mechanics that aren't
necessarily desirable. Something like:
```d
ErrorHandler error = registerErrorHandler;
error.onFailure({writeln("division failed");});
On Wednesday, 25 August 2021 at 14:52:34 UTC, Steven
Schveighoffer wrote:
On 8/25/21 10:42 AM, Steven Schveighoffer wrote:
I think it's possible to work with some mechanics that aren't
necessarily desirable. Something like:
One has to weigh how much this is preferred to actual exception
On Wednesday, 25 August 2021 at 14:42:07 UTC, Steven
Schveighoffer wrote:
On 8/25/21 10:22 AM, Paul Backus wrote:
On Wednesday, 25 August 2021 at 14:04:54 UTC, WebFreak001
wrote:
[...]
Probably the only principled way to make this work would be to
define some kind of "concept"/structural
On 8/25/21 10:42 AM, Steven Schveighoffer wrote:
I think it's possible to work with some mechanics that aren't
necessarily desirable. Something like:
One has to weigh how much this is preferred to actual exception handling...
If something like DIP1008 could become usable, it might
On 8/25/21 10:22 AM, Paul Backus wrote:
On Wednesday, 25 August 2021 at 14:04:54 UTC, WebFreak001 wrote:
Would it be possible to extend `scope(exit)` and `scope(success)` to
trigger properly for functions returning `Expected!T` as defined in
the
On Monday, 23 August 2021 at 17:59:44 UTC, Mahdi wrote:
I made this video for people asking how to configure Dlang in
Emacs environment:) :
https://peertube.linuxrocks.online/w/62pWpmw2r4Se1XvmYiWm75
cool, I think you might wanna post this in General or Announce
instead so more people see
On Wednesday, 25 August 2021 at 14:22:26 UTC, Paul Backus wrote:
On Wednesday, 25 August 2021 at 14:04:54 UTC, WebFreak001 wrote:
[...]
Probably the only principled way to make this work would be to
define some kind of "concept"/structural interface that's
recognized by the compiler to mean
On Wednesday, 25 August 2021 at 14:04:54 UTC, WebFreak001 wrote:
Would it be possible to extend `scope(exit)` and
`scope(success)` to trigger properly for functions returning
`Expected!T` as defined in the
[expectations](https://code.dlang.org/packages/expectations)
and
Would it be possible to extend `scope(exit)` and `scope(success)`
to trigger properly for functions returning `Expected!T` as
defined in the
[expectations](https://code.dlang.org/packages/expectations) and
[expected](https://code.dlang.org/packages/expected) DUB
libraries?
For example is it
On Tuesday, 24 August 2021 at 10:33:07 UTC, JG wrote:
The reason for the crash boils down to the fact that this fails:
foreach(k; sort!"a > b"(funcs.keys)) assert(k in funcs);
funcs is of type ubyte[4][float]
Is this a compiler bug?
That assert will fail if there are NaN keys in the AA.
On Wednesday, 25 August 2021 at 12:23:06 UTC, Adam D Ruppe wrote:
...
Thanks - that explains in all.
On Wednesday, 25 August 2021 at 12:23:32 UTC, FeepingCreature
wrote:
class Alias_Class
{
Test_Struct ts;
Test_Struct getter() { return ts; }
alias getter this;
}
Good idea,
On Wednesday, 25 August 2021 at 12:23:06 UTC, Adam D Ruppe wrote:
[snip]
That's a lot about alias this that I didn't know. Thanks.
On Wednesday, 25 August 2021 at 12:11:01 UTC, Johann Lermer wrote:
Hi all,
I have a little problem understanding alias this. I always
thought, that alias this only makes implicit conversions from
the aliased object to this. Then, why do lines 18 and 22
compile in the code below? And, btw,
On Wednesday, 25 August 2021 at 12:11:01 UTC, Johann Lermer wrote:
I have a little problem understanding alias this. I always
thought, that alias this only makes implicit conversions from
the aliased object to this.
What it does is if "a SOMETHING b" doesn't compile, it instead
tries
On Wednesday, 25 August 2021 at 12:11:01 UTC, Johann Lermer wrote:
```d
14 void main ()
15 {
16 auto ac = new Alias_Class;
17 Test_Struct ts = ac; // compiles
18 ac = ts; // compiles as well - why?
19
20 auto tc = new Test_Class;
21 ts = tc.ac; //
Hi all,
I have a little problem understanding alias this. I always
thought, that alias this only makes implicit conversions from the
aliased object to this. Then, why do lines 18 and 22 compile in
the code below? And, btw, line 22 crashes with a segmentation
fault.
```d
01 struct
On 8/25/21 7:26 AM, Alexandru Ermicioi wrote:
On Wednesday, 25 August 2021 at 11:04:35 UTC, Steven Schveighoffer wrote:
It never has called `save`. It makes a copy, which is almost always
the equivalent `save` implementation.
Really?
Then what is the use for .save method then?
The only
On Wednesday, 25 August 2021 at 11:04:35 UTC, Steven
Schveighoffer wrote:
It never has called `save`. It makes a copy, which is almost
always the equivalent `save` implementation.
-Steve
Really?
Then what is the use for .save method then?
The only reason I can find is that you can't declare
On 8/25/21 6:06 AM, Alexandru Ermicioi wrote:
On Wednesday, 25 August 2021 at 08:15:18 UTC, frame wrote:
I know, but foreach() doesn't call save().
Hmm, this is a regression probably, or I missed the time frame when
foreach moved to use of copy constructor for forward ranges.
Do we have a
On 8/25/21 4:31 AM, frame wrote:
On Tuesday, 24 August 2021 at 21:15:02 UTC, Steven Schveighoffer wrote:
I'm surprised you bring PHP as an example, as it appears their foreach
interface works EXACTLY as D does:
Yeah, but the point is, there is a rewind() method. That is called every
time on
On 8/25/21 6:06 AM, Joseph Rushton Wakeling wrote:
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied when
the foreach loop is created.
That's quite a strong assumption, because its state might be a reference
type, or it
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
That's quite a strong assumption, because its state might be a
reference type, or it might not _have_ state in a meaningful
sense --
On Wednesday, 25 August 2021 at 08:15:18 UTC, frame wrote:
I know, but foreach() doesn't call save().
Hmm, this is a regression probably, or I missed the time frame
when foreach moved to use of copy constructor for forward ranges.
Do we have a well defined description of what input, forward
On Wednesday, 25 August 2021 at 06:51:36 UTC, bauss wrote:
Of course it doesn't disallow classes but it's generally
advised that you use structs and that's what you want in 99% of
the cases. It's usually a red flag when a range starts being a
reference type.
Well, sometimes you can't avoid
On Tuesday, 24 August 2021 at 21:15:02 UTC, Steven Schveighoffer
wrote:
If you have a for loop:
```d
int i;
for(i = 0; i < someArr.length; ++i)
{
if(someArr[i] == desiredValue) break;
}
```
You are saying, "compiler, please execute the `++i` when I
break from the loop because I already
On Tuesday, 24 August 2021 at 18:52:19 UTC, Alexandru Ermicioi
wrote:
Forward range exposes also capability to create save points,
which is actually used by foreach to do, what it is done in
java by iterable interface for example.
I know, but foreach() doesn't call save().
On Tuesday, 24 August 2021 at 19:06:44 UTC, Alexandru Ermicioi
wrote:
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
Actually the range contracts don't mention that it needs to be
a
38 matches
Mail list logo
