On 11/10/18 20:16, Kagamin wrote:
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson wrote:
In the ternary operator it should treat parenthesis directly to the
left as the argument.
I don't think parentheses are ever treated like that. They are
self-contained and don't affect opera
Hello everyone,
First of all, I know I've had a shorter than usual fuse of late. I'd
like to apologize to everyone about this. It is the culmination of quite
a few things increasing the load I'm under.
One of those things is this: October 14th will be my last day working
for Weka.IO. Accordi
I got this as a report from a user, not directly running this, which is
why I'm not opening a bug report.
Consider the following function:
void f(ARGS...)(ARGS args, bool arg1 = true, char arg2 = 'H');
Now consider the following call to it:
f(true, 'S');
Theoretically, this can either be cal
On 04/10/18 13:43, Stanislav Blinov wrote:
* move the data as part of the call hook rather than before
* Use a different name and signature on the hook function
Yes, exactly.
It would have to be special if you don't want to leave room for the
compiler implementors.
That's not how standa
On 04/10/18 11:16, Paolo Invernizzi wrote:
While I want to thank you both, about the quality of this thread, what
kind of "consequences that go beyond what I think you understand" are
you thinking of? Can you give an example?
Assuming I understand Stanislav's proposal correctly (an assumption
On 04/10/18 11:05, Stanislav Blinov wrote:
On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh wrote:
If you do *anything* to that program, and that includes even changing
its compilation flags (try enabling inlining), it will stop working.
You should have known that when you found o
On 03/10/18 23:25, Stanislav Blinov wrote:
It *is* true when the type doesn't have a destructor. Extending that to
a move hook, it will also be true because destruction will be elided.
I know what you're talking about, that happens for types that have
destructors.
No, destructors have nothing
On 03/10/18 20:43, Stanislav Blinov wrote:
On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh wrote:
I.e. - I am asserting if a move was not caught. The program fails to
run on either ldc or dmd. To me, this makes perfect sense as for the
way D is built. In essence, opAssign isn't
On 03/10/18 12:48, Corel wrote:
The fact that in D the structures to date are not moved, is known for
years ... take advantage of this fact, and move on.
I have no idea where you got this fact:
import std.stdio;
struct MoveTest {
static uint counter=1;
uint id;
@disable this(this
On 03/10/18 18:33, Shachar Shemesh wrote:
~this() {
writefln("%s destructed", &this);
assert(counter is null || counter is &localCounter);
}
You might also want to add @disable this(this); and remove the dead code
(i.e. - the case where the pointer is global) to re
On 03/10/18 17:29, Stanislav Blinov wrote:
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
Yes. I am actually sorry about that. I was responding to your assumption
that I'm wrong. Had your post been phrased as
On 03/10/18 16:56, Stanislav Blinov wrote:
struct S {
this(S rhs);
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
And this simply and utterly doesn't work.
If you read the DIP, you will notice that the *address* in which the old
instance resides is quite important f
On 03/10/18 04:10, Walter Bright wrote:
On 10/2/2018 4:30 PM, Adam D. Ruppe wrote:
On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote:
Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler
moved structs in a number of situations - e.g. when the return value
was an rv
On 30/09/18 10:26, Manu wrote:
Other implementations make much better use of that built-in space by
not wasting 8 bytes on an interior pointer for small-strings.
I will point out that a pointer that *sometimes* points to an internal
member was one of the use cases I documented when I submitt
On Saturday, 29 September 2018 at 16:19:38 UTC, ag0aep6g wrote:
On 09/29/2018 04:19 PM, Shachar Shemesh wrote:
On 29/09/18 16:52, Dukc wrote:
[...]
I know you meant Sarn, but still... can you please be a bit
less aggresive with our wording?
From the article (the furthest point I read in it)
On 29/09/18 16:52, Dukc wrote:
On Saturday, 29 September 2018 at 02:22:55 UTC, Shachar Shemesh wrote:
I missed something he said in one of the other (as of this writing,
98) posts of this thread, and thus causing Dukc to label me a
bullshitter.
I know you meant Sarn, but still... can you plea
On 28/09/18 14:37, Dukc wrote:
On Friday, 28 September 2018 at 02:23:32 UTC, sarn wrote:
Shachar seems to be aiming for an internet high score by shooting down
threads without reading them. You have better things to do.
http://www.paulgraham.com/vb.html
I believe you're being too harsh. It
On 27/09/18 16:38, aliak wrote:
The point was that being able to use non-English in code is demonstrably
both helpful and useful to people. Norwegian happens to be easily
anglicize-able. I've already linked to non ascii code versions in a
previous post if you want that too.
If you wish to mak
On 27/09/18 10:35, aliak wrote:
Here's an example from this years spring semester and NTNU (norwegian
uni): http://folk.ntnu.no/frh/grprog/eksempel/eks_20.cpp
... That's the basic programming course. Whether the professor would use
that I guess would depend on ratio of English/non-English spea
On 27/09/18 04:54, Nick Sabalausky (Abscissa) wrote:
Man, I wish SOO much, that was true of my favorite editor (Programmer's
Notepad 2). I love it, but it's a windows thing and has some issues
under wine.
Can you elaborate on what issues? Merely downloading and installing seem
to work fine.
On 26/09/18 10:26, Dukc wrote:
On Wednesday, 26 September 2018 at 06:50:47 UTC, Shachar Shemesh wrote:
The properties that cause city names to be poor candidates for enum
values are the same as those that make them Unicode candidates.
How so?
City names (data, changes over time) as enums (com
On 25/09/18 15:35, Dukc wrote:
Another reason is that something may not have a good translation to
English. If there is an enum type listing city names, it is IMO better
to write them as normal, using Unicode. CityName.seinäjoki, not
CityName.seinaejoki.
This sounded like a very compelling ex
On 23/09/18 15:38, sarn wrote:
On Sunday, 23 September 2018 at 06:53:21 UTC, Shachar Shemesh wrote:
On 23/09/18 04:29, sarn wrote:
You can find a lot more Japanese D code on this blogging platform:
https://qiita.com/tags/dlang
Here's the most recent post to save you a click:
https://qiita.com/
On 23/09/18 04:29, sarn wrote:
On Sunday, 23 September 2018 at 00:18:06 UTC, Adam D. Ruppe wrote:
I have seen Japanese D code before on twitter, but cannot find it now
(surely because the search engines also share this bias).
You can find a lot more Japanese D code on this blogging platform:
h
On 22/09/18 15:13, Thomas Mader wrote:
Would you suggest to remove such writing systems out of Unicode?
What should a museum do which is in need of a software to somehow manage
Egyptian hieroglyphs?
If memory serves me right, hieroglyphs actually represent consonants
(vowels are implicit), an
On 22/09/18 14:28, Jonathan M Davis wrote:
As I said, it's exactly the same
as arguing that words should be represented in Unicode. Unfortunately,
however, at least some of them are in there. :|
- Jonathan M Davis
To be fair to them, that word is part of the "Arabic-representation
forms" sect
On 22/09/18 11:52, Jonathan M Davis wrote:
Honestly, I was horrified to find out that emojis were even in Unicode. It
makes no sense whatsover. Emojis are supposed to be sequences of characters
that can be interepreted as images. Treating them like Unicode symbols is
like treating entire words l
On 19/09/18 22:53, Walter Bright wrote:
On 9/19/2018 10:13 AM, Shachar Shemesh wrote:
assert(condition, string); // string is useless without actual info
about what went wrong.
assert(condition, format(string, arg, arg)); // No good - format is
not @nogc
Another method:
debug
a
On 19/09/18 21:35, Steven Schveighoffer wrote:
On 9/19/18 1:13 PM, Shachar Shemesh wrote:
There is a catch, though. Writing Mecca with @nogc required
re-implementing quite a bit of druntime. Mecca uses its own exception
allocations (mkEx, just saw it's not yet documented, it's under
mecca.lib
On 08/09/18 11:07, Peter Alexander wrote:
I'd love to know if anyone is making good use of @nogc in a larger code
base and is happy with it. Weka.io?
No, sorry.
Actually, yes.
Well, sortof.
The main Weka codebase hardly uses any annotations of any kind. Not
@nogc nor others. This is in the
I've got plenty to say, but here is the long and the short of it: Use Mecca.
On 07/09/18 19:44, Peter Alexander wrote:
3. It was really frustrating that I had to make the compiler happy
before I was able to run anything again. Due to point #1 I had to move
code around to restructure things and
On 07/09/18 09:42, Don wrote:
A loop is not possible in ordinary operation, any more than a loop is
possible in a depth-first traverse of a tree. But, what I don't know is,
what happens if there is a switch to a different fiber inside a
`finally` clause?
I never considered that.
Each fiber m
On 31/08/18 23:22, Steven Schveighoffer wrote:
On 8/31/18 3:50 PM, Walter Bright wrote:
https://news.ycombinator.com/item?id=17880722
Typical comments:
"`assertAndContinue` crashes in dev and logs an error and keeps going
in prod. Each time we want to verify a runtime assumption, we decide
w
On 25/08/18 10:56, Walter Bright wrote:
On 8/24/2018 6:34 AM, Shachar Shemesh wrote:
No, unlike what I suggest, that doesn't work without carefully
reviewing every single place you put it to see whether the constructor
actually supports destructing a partially constructed object.
All D object
On 24/08/18 13:43, nkm1 wrote:
I think Walter was talking more about "scope (failure) destroy(this)" at
the top of all your structs? I don't know if it has some gotchas, though
(as I don't use RAII in D...).
No, unlike what I suggest, that doesn't work without carefully reviewing
every si
On 23/08/18 15:03, Walter Bright wrote:
So you will excuse me, but I don't think this bug is being taken as
seriously as I think it should.
It is a serious problem. (There are workarounds available, like using
scope(failure).)
I don't think you understand how unworkable this workaround is.
On 24/08/18 10:43, FeepingCreature wrote:
Have you tried to use the excellent Dustmite tool? It's never failed to
reduce a bug for me.
Dustmite might be excellent. I wouldn't know. It cannot swallow the Weka
code base.
Shachar
On 24/08/18 05:33, Jonathan M Davis wrote:
Yeah. I've used RAII plenty in D without problems, but the fact remains that
certain uses of it are very broken right now thanks to the constructor
issue. I suspect that Shachar's as negative about this as he is in part
because having RAII go wrong with
On 23/08/18 23:46, Walter Bright wrote:
In my experience with debugging code, if drilling down to find the cause
of the problem is not done, there is no way to conclude whether whether
it is a compiler bug or a user bug.
(Of course, compiler internal errors are always compiler bugs.)
Drilling
On 23/08/18 20:57, bachmeier wrote:
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh wrote:
If you can, feel free to contact me off-list, and I'm fairly sure we
can get the budget for you to work on it. The same goes for anyone
else on this list.
I don't think Kenji will see your
On 23/08/18 20:52, bachmeier wrote:
On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote:
On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote:
On 23/08/18 17:01, Steven Schveighoffer wrote:
My main job is to develop for Weka, not develop D itself.
Weka, at some point, made th
On 23/08/18 19:58, RhyS wrote:
A quick question, if Weka did not have the current 300k backlog of code,
what language of choice is more likely to be picked by the team at Weka?
I don't know. Like I said, while the feeling that D has completely lost
its way is fairly universal, the claim that
On 23/08/18 18:35, Joakim wrote:
So your example of a fatal flaw is that D could be 100X faster at
compilation instead of just 10X than most every other native language
out there?! C'mon.
Have you tried Stephan's example yet?
static foreach(i; 0..16384) {}
Do give it a shot, tell me wha
On 23/08/18 17:01, Steven Schveighoffer wrote:
So interestingly, you are accepting the sockaddr by VALUE.
Indeed. The reason is that I cannot accept them by reference, as then
you wouldn't be able to pass lvalues in. Another controversial decision
by D.
Had that been C++, I'd definitely get
On 23/08/18 17:01, Steven Schveighoffer wrote:
If they are blocking
your work, complain about them loudly, every day. But not filing them
doesn't help anyone.
The economics don't add up.
If a bug is blocking my work, there are two options:
1. I work around it, at which point it is no longer
On 23/08/18 15:55, Steven Schveighoffer wrote:
This whole thread seems very gloomy and final, but I feel like the tone
does not match in my mind how D is progressing. "Every single one of the
people [at Weka] rushing to defend D at the time has since come around."
Seems like you all have decide
On 23/08/18 14:02, Walter Bright wrote:
On 8/23/2018 2:09 AM, Shachar Shemesh wrote:
functions may be @safe, nothrow, @nogc, pure. If it's a method it
might also be const/inout/immutable, static. The number of libraries
that support all combinations is exactly zero (e.g. - when passing a
deleg
On 23/08/18 09:58, Joakim wrote:
Because you've not listed any here, which makes you no better than some noob
Here's one: the forum does not respond well to criticism.
Here's an incredibly partial list:
* Features not playing well together.
Despite what Joakim seems to think, I've actually
On 23/08/18 09:17, Jacob Carlborg wrote:
On Thursday, 23 August 2018 at 05:37:12 UTC, Shachar Shemesh wrote:
One that hurt me lately was a way to pass a scoped lazy argument (i.e.
- to specify that the implicit delegate need not allocate its frame,
because it is not used outside the function c
On 23/08/18 09:04, Mike Franklin wrote:
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:
And it's not just Weka. I've had a chance to talk in private to some
other developers. Quite a lot have serious, fundamental issues with
the language. You will notice none of them speaks
On 23/08/18 08:20, Nicholas Wilson wrote:
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:
No, no and no.
I was holding out on replying to this thread to see how the community
would react. The vibe I'm getting, however, is that the people who are
seeing D's problems have gi
On 23/08/18 07:35, Dukc wrote:
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote:
Every single one of the people rushing to defend D at the time has
since come around. There is still some debate on whether, points vs.
counter points, choosing D was a good idea, but the overwhel
On 22/08/18 21:34, Ali wrote:
On Wednesday, 22 August 2018 at 17:42:56 UTC, Joakim wrote:
Pretty positive overall, and the negatives he mentions are fairly
obvious to anyone paying attention.
Yea, I agree, the negatives are not really negative
Walter not matter how smart he is, he is one man
On 22/03/18 16:45, Radu wrote:
On Thursday, 22 March 2018 at 11:58:02 UTC, Shachar Shemesh wrote:
On 22/03/18 12:28, Meta wrote:
On Wednesday, 21 March 2018 at 12:52:19 UTC, Paulo Pinto wrote:
[...]
"The central failure of the language is the myopic focus on the
affine typing solution to he
On 01/08/18 17:13, Steven Schveighoffer wrote:
The lazy variadic thing is a distinction between specifying variadic
lazy parameters and a lazy variadic array.
I have now read that sentence 4 times, and I still have no idea what it
means.
Can you give examples of both?
Shachar
On 01/08/18 17:13, Steven Schveighoffer wrote:
On 8/1/18 3:59 AM, Shachar Shemesh wrote:
Thank you! Finally!
Let me just state, for the record, that having *yet another* syntax
special case is just appalling.
The lazy variadic thing is a distinction between specifying variadic
lazy paramete
Thank you! Finally!
Let me just state, for the record, that having *yet another* syntax
special case is just appalling.
With that said, I was hoping that specifying it explicitly as a delegate
would allow me to scope it. Apparently, that doesn't work :-(
Shachar
On 31/07/18 23:03, ag0aep6g
On 31/07/18 10:29, Mike Franklin wrote:
Please clarify if I'm missing the point.
You are. I want something along the lines of:
assertEQ(a, b, "a and b are not equal");
When run, it would issue an assert that says:
Assertion failed: 3!=7: a and b are not equal
Hooking it later is not an option
I'm trying to figure out what's the signature of the built-in assert. It
does not seem that I can define a similar function myself.
First attempt:
void myAssert(bool cond, string msg) @nogc nothrow;
No, because msg gets evaluated unconditionally.
void myAssert(bool cond, lazy string msg) @nogc
On 26/07/18 10:31, Seb wrote:
On Thursday, 26 July 2018 at 05:52:51 UTC, Shachar Shemesh wrote:
At which point I'm stuck. I don't know how D's catch matching works,
so I don't know where to continue looking.
https://github.com/dlang/druntime/blob/master/src/rt/dwarfeh.d
You still use druntime
On 26/07/18 09:22, rikki cattermole wrote:
Hmm, sounds like the vtable and hence TypeInfo part of the reference is
getting corrupted.
Have you checked that the type matches where you throw it?
Is that what "classinfo" returns? Because if so, it's printed by the
logs I pasted in my question,
Under mecca, we're using GC free exceptions.
I have code that uses mkEx
(https://github.com/weka-io/mecca/blob/master/src/mecca/lib/exception.d#L307).
Essentially, it constructs an exception in place inside a fiber-local
buffer. The construction code seems correct, and the parent seems set
co
Forget the "why" for the moment.
T construct(T, ARGS...)(ARGS args) if( is(T==class) ) {
auto buffer = new ubyte[__traits(classInstanceSize, T)];
T cls = cast(T)buffer.ptr;
// Is this really the best way to do this?
buffer[] = cast(ubyte[])typeid(T).initializer()[];
cls.__ctor(arg
On 17/07/18 16:29, aliak00 wrote:
A postblit on a class issues a compiler error. And an identity opAssign
on a class also issues a compiler error. So I'm not sure how this would
be different. And the page In
https://dlang.org/spec/operatoroverloading.html also explicitly mentions
differences
On 14/07/18 15:56, Johan Engelen wrote:
First off: I am trying to wear a strict language lawyer hat. D spec is
already very much ill specced which is _very_ problematic for language
and compiler development. I am not attacking the proposal in order to
kill it. I am merely commenting on points t
On 12/07/18 04:17, Jonathan M Davis wrote:> I'm also> not sure if going
to copy constructors means that we should do something> different with
this. It don't think that it's affected by it, but I could be> missing
something.
I actually had that very same concern myself. Andrei does not seem to
On 29/06/18 15:35, aliak wrote:
On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote:
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
Thanks in advance for your participation.
For those of you using the NNTP or mailing list interfaces, this is
the thread to respond i
On 11/07/18 20:04, Johan Engelen wrote:
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
DIP 1014, "Hooking D's struct move semantics", is now ready for final
review.
after quick read:
(would be much easier to do inline commenting, but it appears that's not
supported)
### Sec
On 28/06/18 01:46, Steven Schveighoffer wrote:
This has been a thorn in many sides for a long time. I remember
Weka.io's Liran talking about how they required an INSANE amount of
time/memory to build their system in dconf 2015 maybe? But things have
gotten a bit better since then. I think at so
On 14/06/18 13:39, DigitalDesigns wrote:
Wait? Are you sure you are not kidding? Do you want another shot?
No, I'm fine. Thank you. I am not out here to convert anyone. If you
want to believe the magic of obfuscation, go right ahead.
You can probably even leverage D's CTFE to do it inside t
On 14/06/18 08:21, DigitalDesigns wrote:
On Thursday, 14 June 2018 at 02:13:58 UTC, Shachar Shemesh wrote:
With that said, what you're trying to achieve is probably not a good
idea anyways. With very few exceptions(1), reverse-engineering code to
figure out what it does is not considerably more
On 14/06/18 03:01, DigitalDesigns wrote:
Is there an obfuscator for D that at least renames identifiers? This is
because sometimes they leak from various processes and could be
potential sources of attack.
It would be a tool that probably just replaces their values with, say
their hash + some
On 05/06/18 11:26, Nicholas Wilson wrote:
writeln("Exception"); // Why is this not caught? I've no
idea
That's the part I was referring to.
I set up to find out what happens if the assert string throws. I have to
admit I did not expect the result:
$ cat test.d
import std.stdio;
import core.exception;
void main() {
scope(failure) {
writeln("Not gonna happen");
}
try {
static string throwingFunc() {
On 18/05/18 22:57, kinke wrote:
I checked, and the reason is that D and C++ use a different ABI wrt.
by-value passing of non-POD arguments. C++ indeed passes a reference to
a caller-allocated rvalue, not just on Win64; that makes it trivial, as
there are no moves across call boundaries. But you
On 17/05/18 22:29, Manu wrote:
This is great!
I've wanted this on numerous occasions when interacting with C++ code.
This will make interaction more complete.
Within self-contained D code, I have avoided self-pointers by using
self-offsets instead in the past (a bit hack-ey). But this nicely
ti
On 17/05/18 19:08, Kagamin wrote:
On Thursday, 17 May 2018 at 13:50:26 UTC, Shachar Shemesh wrote:
There is no such use case. Please remember that at the time opPostMove
is called, both new and old memory are still allocated.
That's an interesting moment too. A struct that was supposed to be m
On 17/05/18 18:47, kinke wrote:
On Thursday, 17 May 2018 at 15:23:50 UTC, kinke wrote:
See IR for https://run.dlang.io/is/1JIsk7.
I should probably emphasize that the LLVM `byval` attribute is strange
at first sight. Pseudo-IR `void foo(S* byval param); ... foo(S* byarg
arg);` doesn't mean t
On 17/05/18 16:42, Kagamin wrote:
Looks like requirement for @nogc @safe has no consequence as the DIP
suggests to infer them anyway. On ideological side safety can't be a
requirement because it would contradict its purpose of providing
guarantee.
I think you are confusing __move_post_blt's i
I'm not sure I follow all of your comments.
For the rest my comments, let's assume that the compiler may assume that
__move_post_blt is a no-op if hasElaborateMove returns false.
On 17/05/18 14:33, kinke wrote:
3. When deciding to move a struct instance, the compiler MUST emit a
call to the s
On 17/05/18 11:22, rikki cattermole wrote:
What is the benefit of opPostMove over copy constructors (not postblit)?
The two are unrelated. A copy is a very different operation from a move.
With a copy, you have to figure out how to duplicate the resources used
by the object. With a move, no
At least under Linux, you cannot get or set the value of errno from a
nothrow function.
Is this on purpose, or is this a bug?
Shachar
On 09/05/18 01:09, David Nadlinger wrote:
The algorithm isn't wait-free (haven't thought too carefully about this,
though)
This mirrors a discussion I had with Maor (who originally wrote it).
Let's see if I bring you around the way I was brought around.
At the API level, there are two areas
On 09/05/18 03:20, Andy Smith wrote:
During Shachar's talk on the Saturday morning following the conclusion
of Dconf he made it clear that the Mecca library is being used by the
~200klock Weka.io codebase ... a codebase which has very stringent
latency *and* throughput requirements to satisfy
On 08/05/18 07:00, manumaster wrote:
Is there some implement like this in D ?
https://github.com/pramalhe/ConcurrencyFreaks/blob/master/papers/multilist-2017.pdf
It's two of Mecca's containers:
https://weka-io.github.io/mecca/docs/mecca/containers/otm_queue.html
Hello everybody,
I'll be arriving in Munich on the morning of May 1st. I was wondering
whether anyone has any recommendations as to how to spend that day?
Thanks,
Shachar
import std.exception;
struct AA(Key, Val) {
Val[Key] aa;
alias aa this;
void opIndexAssign(inout Val value, Key key) pure {
aa[key] = value;
}
}
void main() {
AA!(string, int) a;
//compile error -- no property 'remove' for type
'CheckedAA!(string, int)'
a.
On 17/04/18 13:59, Simen Kjærås wrote:
There's a kinda neat (and kinda ugly) way to implement prop in one line:
enum prop(T) = __traits(compiles, { static assert(T.member == 3); });
Now, that's not the same as short-circuiting, and only useful in some
cases, but for those cases, it's usef
This is going nowhere.
Let's flesh this out face to face at dconf.
Shachar
On 16/04/18 12:01, Jonathan M Davis wrote:
On Monday, April 16, 2018 07:15:36 Shachar Shemesh via Digitalmars-d wrote:
On 16/04/18 01:28, Jonathan M Davis wrote:
The fact that foreach copies the range that it&#x
Consider the following program:
struct S1 {
enum member = 3;
}
struct S2 {
enum member = 2;
}
struct S3 {
}
enum prop(T) = __traits(hasMember, T, "member") && T.member==3;
pragma(msg, prop!S1);
pragma(msg, prop!S2);
pragma(msg, prop!S3);
When compiled, it produces:
true
false
test.d(
On 16/04/18 01:28, Jonathan M Davis wrote:
The fact that foreach copies the range that it's given makes using ref with
anything other than arrays a bit of an iffy proposition. It will compile
regardless of whether front returns by ref or not (which arguably is a bug),
but it will only affect the
On 15/04/18 09:39, Jonathan M Davis wrote:
It's extremely common for range-based functions to copy front. Even foreach
does it. e.g.
Not necessarily:
foreach(ref e; [S(0), S(1), S(2)]){}
While that would work with foreach, it will not work with anything that
expects an inputRange (and sinc
import std.range;
import std.stdio;
struct S {
int a;
@disable this(this);
}
void main() {
writeln(isInputRange!(S[])); // Prints false
}
The reason, as far as I can tell, is that an input range requires that
we can do:
auto a = ir.front; // Assuming ir isn't empty
That doesn't
On 12/04/18 18:42, Uknown wrote:
On Thursday, 12 April 2018 at 12:16:53 UTC, Shachar Shemesh wrote:
[...]
test.d(19): Error: cannot convert &S to const(ubyte*) at compile time
[...]
Thank you,
Shachar
The problem seems to be that cast is happening at compile time, as
opposed to run time, as y
I'm trying to build a wrapper that will allow you to copy structs that
have members that disabled copying. The idea is that copying these
members will revert them to init.
This is what I have so far:
struct NoCopy(T) {
static assert( !hasElaborateDestructor!T, "NoCopy does not support
typ
On 11/04/18 11:51, Uknown wrote:
On Wednesday, 11 April 2018 at 08:47:12 UTC, Basile B. wrote:
On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh wrote:
struct S {
static void func(T)(uint a, T t) {
}
static void func() {
}
}
Your mission, Jim, should you choose to a
struct S {
static void func(T)(uint a, T t) {
}
static void func() {
}
}
Your mission, Jim, should you choose to accept it, is this:
Get a pointer to the version of the function that accepts no arguments.
As always, should you or any of your Force be caught or killed, the
Secr
On 11/04/18 10:58, Jonathan M Davis wrote:
All objects are initialized with their init values prior to the constructor
being called. So, whether an object is simply default-initialized or whether
the constructor is called, you're going to get the same behavior except for
the fact that the constru
On 09/04/18 14:22, Jonathan M Davis wrote:
On Monday, April 09, 2018 14:06:50 Shachar Shemesh via Digitalmars-d wrote:
struct S {
int a;
int[5000] arr = void;
}
void func() {
S s;
}
During the s initialization, the entire "S" area is initialized,
including the member ar
struct S {
int a;
int[5000] arr = void;
}
void func() {
S s;
}
During the s initialization, the entire "S" area is initialized,
including the member arr which we asked to be = void.
Is this a bug?
Shachar
1 - 100 of 358 matches
Mail list logo
