On Monday, 22 October 2018 at 11:24:27 UTC, Dukc wrote:
Frankly, this does not sound credible. According to this
rationale, array access should be @system too, because it
relies on the array not giving direct access to its length to
the user, which would also in itself be @safe.
For reading,
On Monday, 22 October 2018 at 00:55:00 UTC, Timon Gehr wrote:
On 22.10.18 02:46, Nicholas Wilson wrote:
On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
I just did,
Link please?
https://forum.dlang.org/post/pqii8k$11u3$1...@digitalmars.com
That contains no code.
Not all of
On Monday, 22 October 2018 at 00:46:04 UTC, Walter Bright wrote:
That's what I was referring to, and Manu's example. It doesn't
work, as I pointed out.
I'm pretty sure it does, but please repeat it.
We will eventually. This started as a "please point out any
problems with this" and has probab
On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
I just did,
Link please?
On Monday, 22 October 2018 at 00:32:35 UTC, Timon Gehr wrote:
This only works if untrusted programmers (i.e. programmers who
are only allowed to write/modify @safe code) are not allowed to
change your class. I.e. it does not work.
This is the basis of the current @safe/@trusted/@system model.
On Sunday, 21 October 2018 at 22:12:18 UTC, Neia Neutuladh wrote:
On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote:
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
Note that there may well be a good way to get the good
properties of MP without breaking the type system, but M
On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit
conversion in the other direction, which is not part of the
proposal.
It's Man
On Sunday, 21 October 2018 at 19:07:37 UTC, Nicholas Wilson wrote:
On Sunday, 21 October 2018 at 09:50:09 UTC, Walter Bright wrote:
Your proposal makes that impossible because the compiler would
allow unshared data to be implicitly typed as shared.
Yes, but not the other way around.
Whoops t
On Sunday, 21 October 2018 at 09:50:09 UTC, Walter Bright wrote:
Manu's Proposal ---
@safe:
int i;
int* a = &i;
StartNewThread(a); // Compiles! Coder has no idea!
... in the new thread ...
void StartOfNewThread(shared(int)* b) {
... we have two threads accessing 'i',
one thinks it
On Sunday, 21 October 2018 at 09:58:18 UTC, Walter Bright wrote:
On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
You can if no-one else writes to it, which is the whole point
of Manu's proposal. Perhaps it should be const shared instead
of shared but still.
There is no purpose whatsoever to da
On Saturday, 20 October 2018 at 17:06:22 UTC, Stanislav Blinov
wrote:
On Saturday, 20 October 2018 at 16:48:05 UTC, Nicholas Wilson
wrote:
On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright
wrote:
by code that believes it is unshared
you cannot `@safe`ly modify the memory through `b
On Saturday, 20 October 2018 at 16:41:41 UTC, Stanislav Blinov
wrote:
On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
class C {
void f();
void g() shared;
}
void t1(shared C c) {
c.g; // ok
c.f; // error
}
void t2(shared C c) {
c.g; // ok
c.f; // error
}
auto c = new C
On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright wrote:
On 10/19/2018 11:18 PM, Manu wrote:
The reason I ask is because, by my definition, if you have:
int* a;
shared(int)* b = a;
While you have 2 numbers that address the same data, it is not
actually aliased because only `a` can ac
On Saturday, 20 October 2018 at 00:00:49 UTC, Dominikus Dittes
Scherkl wrote:
Hmm.
mutable, immutable and const form a triple, the second is a
declaration attribute, the last an parameter attribute,
indicating that you don't want to modify the parameter, may it
be because you can't (as it is i
On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote:
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
How is the exception destroyed when dip1008 is enabled?
Apparently, it isn't. Which renders dip1008 pretty much useless
since we could already use static
On Wednesday, 17 October 2018 at 15:51:04 UTC, Steven
Schveighoffer wrote:
On 10/17/18 9:58 AM, Nicholas Wilson wrote:
On Wednesday, 17 October 2018 at 13:25:28 UTC, Steven
Schveighoffer wrote:
It's identical to the top one. You now have a new unshared
reference to shared data. This is done WIT
On Wednesday, 17 October 2018 at 14:26:43 UTC, Timon Gehr wrote:
On 17.10.2018 16:14, Nicholas Wilson wrote:
I was thinking that mutable -> shared const as apposed to
mutable -> shared would get around the issues that Timon
posted.
Unfortunately not. For example, the thread with the mutable
On Wednesday, 17 October 2018 at 07:24:13 UTC, Stanislav Blinov
wrote:
On Wednesday, 17 October 2018 at 05:40:41 UTC, Walter Bright
wrote:
When Andrei and I came up with the rules for:
mutable
const
shared
const shared
immutable
and which can be implicitly converted to what, s
On Wednesday, 17 October 2018 at 13:25:28 UTC, Steven
Schveighoffer wrote:
On 10/16/18 8:26 PM, Manu wrote:
On Tue, Oct 16, 2018 at 2:20 PM Steven Schveighoffer via
Digitalmars-d
wrote:
There is in fact, no difference between:
int *p;
shared int *p2 = p;
int *p3 = cast(int*)p2;
Totally ill
On Wednesday, 17 October 2018 at 00:29:04 UTC, Manu wrote:
On Tue, Oct 16, 2018 at 3:25 PM Nicholas Wilson via
Digitalmars-d wrote:
On Tuesday, 16 October 2018 at 21:19:26 UTC, Steven
Schveighoffer wrote:
> There is in fact, no difference between:
>
> int *p;
> shared int *p2 =
On Tuesday, 16 October 2018 at 21:19:26 UTC, Steven Schveighoffer
wrote:
There is in fact, no difference between:
int *p;
shared int *p2 = p;
int *p3 = cast(int*)p2;
and this:
int *p;
shared int *p2 = p;
int *p3 = p;
If I understand Manu correctly the first should compile, and the
second sh
On Tuesday, 16 October 2018 at 21:19:26 UTC, Steven Schveighoffer
wrote:
OK, so here is where I think I misunderstood your point. When
you said a lock-free queue would be unusable if it wasn't
shared, I thought you meant it would be unusable if we didn't
allow the implicit cast. But I realize n
On Monday, 15 October 2018 at 23:30:43 UTC, Stanislav Blinov
wrote:
On Monday, 15 October 2018 at 21:51:43 UTC, Manu wrote:
If a shared method is incompatible with an unshared method,
your class is broken.
What?!? So... my unshared methods should also perform all
that's necessary for `shared
On Monday, 15 October 2018 at 21:08:38 UTC, Manu wrote:
On Mon, Oct 15, 2018 at 2:05 PM Nicholas Wilson via
Digitalmars-d wrote:
I'm saying that while what you propose sounds very reasonable,
we should make sure that reading immutable variables is still
good ;)
I don't think what
On Monday, 15 October 2018 at 20:54:12 UTC, jmh530 wrote:
On Monday, 15 October 2018 at 20:44:35 UTC, Manu wrote:
snip
Are you saying `is(immutable(int) == shared) == true)` ??
From the spec:
"Applying any qualifier to immutable T results in immutable T.
This makes immutable a fixed point of
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Destroy...
Keep in mind immutable is implicitly shared (i.e. not in tls)
because nobody can change it. It should stay readable for this
reason.
On Monday, 15 October 2018 at 19:14:58 UTC, Peter Alexander wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
2. object may have shared methods; such methods CAN be called
on
shared instances. such methods may internally implement
synchronisation to perform their function. perhaps
On Friday, 12 October 2018 at 20:12:26 UTC, Stanislav Blinov
wrote:
On Friday, 12 October 2018 at 19:55:02 UTC, Nicholas Wilson
wrote:
Freeing your mind and the codebase of having to deal with
memory leaves it in an easier place to deal with the less
common higher impact leaks: file descripto
On Friday, 12 October 2018 at 19:43:02 UTC, Stanislav Blinov
wrote:
On Friday, 12 October 2018 at 18:50:26 UTC, Neia Neutuladh
wrote:
Over the lifetime of the script, it processed more memory than
my computer had. That means I needed a memory management
strategy other than "allocate everythin
On Tuesday, 9 October 2018 at 18:07:44 UTC, Márcio Martins wrote:
On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
Sorry for the late ping, b
On Sunday, 7 October 2018 at 01:59:21 UTC, Manu wrote:
So I'm working on a SMT infrastructure, and expression of
thread-safety is a core design mechanic... but I'm really
struggling
to express it in terms of the type system.
I figure I'll throw some design challenges out here and see if
anyone
On Thursday, 4 October 2018 at 13:15:23 UTC, Shachar Shemesh
wrote:
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
On Wednesday, 3 October 2018 at 07:33:44 UTC, Russel Winder wrote:
I have been muttering about this a while. :-)
I know, but this conference was sorta last minute realisation
that it would be very beneficial to attend and I've been rather
busy with it.
Being at another conference clearly ma
On Wednesday, 3 October 2018 at 06:40:28 UTC, Russel Winder wrote:
How about DConf continues, as it should, and people submit
sessions to
ACCU as part of the outreach programme. The call for sessions
opens at
the end of this week and lasts three weeks.
Ow, that does not give me a lot of time,
On Tuesday, 2 October 2018 at 06:26:30 UTC, Joakim wrote:
[snip]
Also you're out by a year :)
On Tuesday, 2 October 2018 at 06:26:30 UTC, Joakim wrote:
I'm sure some thought and planning is now going into the next
DConf, so I'd like to make sure people are aware that the
conference format that DConf uses is dying off, as explained
here:
https://marco.org/2018/01/17/end-of-conference-e
On Monday, 1 October 2018 at 09:55:41 UTC, ag0aep6g wrote:
On 10/01/2018 08:47 AM, Nicholas Wilson wrote:
In order to be safe, a mutable parameter can be implicitly
cast to shared iff the parameter is also scope (that includes
the `this` reference`). With an implicit cast in place of the
expli
On Monday, 1 October 2018 at 08:04:38 UTC, Kagamin wrote:
Shared data may need different algorithms.
Yes, but those same algorithms will work on unshared (they might
be slower but they will work). The reverse is not true, it can
lead to race conditions.
If unshared data is
implicitly conve
On Monday, 1 October 2018 at 06:06:31 UTC, ag0aep6g wrote:
`shared` isn't analogous to `const`. It's analogous to
`immutable`. Functions dealing with `shared` data can assume
that other threads also see the data as `shared`. If you allow
calling `shared` methods on non-`shared` objects, you're
On Monday, 1 October 2018 at 04:22:24 UTC, Manu wrote:
Ah, good point. So, it could only be allowed if scope...
struct Bob
{
void setThing() shared scope;
}
That's going to require far-reaching proliferation of `scope`.
Do we infer `scope` like the other attributes?
For templates (either th
On Monday, 1 October 2018 at 03:33:16 UTC, Manu wrote:
On Sun, Sep 30, 2018 at 8:20 PM Nicholas Wilson via
Digitalmars-d wrote:
On Monday, 1 October 2018 at 02:29:40 UTC, Manu wrote:
> struct Bob
> {
> void setThing() shared;
> }
>
> As I understand, `shared` attr
On Monday, 1 October 2018 at 02:29:40 UTC, Manu wrote:
struct Bob
{
void setThing() shared;
}
As I understand, `shared` attribution intends to guarantee that
I dun
synchronisation internally.
This method is declared shared, so if I have shared instances,
I can
call it... because it must ha
On Wednesday, 26 September 2018 at 12:51:57 UTC, Steven
Schveighoffer wrote:
So anything I do at CTFE has to be betterC as well? That is a
bummer.
This is an artificial, and not really intended, limitation.
Essentially, CTFE has to be a real function. If it's defined,
it's expected to be call
On Friday, 21 September 2018 at 09:21:34 UTC, Petar Kirov
[ZombineDev] wrote:
I have been watching Jonathan Blow's Jai for a while myself.
There are many interesting ideas there, and many of them are
what made me like D so much in the first place. It's very
important to note that the speed clai
On Sunday, 16 September 2018 at 23:59:18 UTC, aliak wrote:
What about:
enum E: bool {
no, yes
}
void main() {
E e = cast(E)(0);
}
Would be illegal I assume?
You have an explicit cast, so no, it would be fine.
On Sunday, 16 September 2018 at 01:47:33 UTC, Mike Franklin wrote:
On Friday, 14 September 2018 at 23:08:34 UTC, Nicholas Wilson
The only thing I think is missing is a flag to accelerate the
process s.t. the examples
f(E.a);
f(E.b);
g(a - b);
can be made to call their int/long overloads strai
On Friday, 14 September 2018 at 13:41:40 UTC, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from
integer and character literals to bool", is now ready for Final
Review. This is a last chance for community feedback before the
DIP is handed off to Walter and Andrei
On Tuesday, 11 September 2018 at 14:58:21 UTC, jmh530 wrote:
Is there any reason why this is not sufficient?
[1] https://run.dlang.io/is/lu6nQ0
Overloads:
https://run.dlang.io/is/m5HGOh
The static asserts being in the constraint affects the template
candidacy viability. Being in the functio
On Tuesday, 11 September 2018 at 07:52:45 UTC, Joakim wrote:
On Tuesday, 11 September 2018 at 07:42:38 UTC, passenger wrote:
On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote:
[...]
Is it possible to develop versus a NVidia Jetson, CUDA
included?
I think so, but I doubt anyone has
On Wednesday, 12 September 2018 at 03:59:30 UTC, Danni Coy wrote:
So my understanding is that the main issue with
extern(C++,"ns") is
functions that have different C++ name-spaces overriding each
other in
unexpected ways.
How feasible is to simply disallow
functions/variables/objects/... with
On Tuesday, 11 September 2018 at 13:08:46 UTC, Steven
Schveighoffer wrote:
On 9/10/18 7:00 PM, Nicholas Wilson wrote:
On Monday, 10 September 2018 at 20:44:46 UTC, Andrei
Alexandrescu wrote:
On 9/10/18 12:46 PM, Steven Schveighoffer wrote:
On 9/10/18 8:58 AM, Steven Schveighoffer wrote:
I'll h
On Monday, 10 September 2018 at 20:44:46 UTC, Andrei Alexandrescu
wrote:
On 9/10/18 12:46 PM, Steven Schveighoffer wrote:
On 9/10/18 8:58 AM, Steven Schveighoffer wrote:
I'll have to figure out why my specialized range doesn't
allow splitting based on " ".
And the answer is: I'm an idiot. For
On Saturday, 8 September 2018 at 22:01:23 UTC, Manu wrote:
[snip]
Is anyone interested in this issue?
https://github.com/dlang/dmd/pull/8677
On Saturday, 8 September 2018 at 22:01:23 UTC, Manu wrote:
TL;DR, debugging is critical and neglected. Mixin is worst
offender.
So, string mixin breaks the debugger. All of a sudden there is
code that's executing that doesn't exist anywhere. We need a
solution to this problem...
As I and ot
On Friday, 7 September 2018 at 19:15:21 UTC, Jonathan M Davis
wrote:
Honestly, I wouldn't rely on anything beyond dub build working
in a consistent manner across projects. As far as I can tell,
you can't actually do anything properly custom with dub test,
and I'm inclined to think that how it a
On Thursday, 6 September 2018 at 16:50:32 UTC, H. S. Teoh wrote:
Again, this strongly suggests the idea I've mentioned a few
times now: *all* packages on code.dlang.org needs to be run
through a CI tester, and success/failure to compile should be
reported back to dlang.org somehow. Then in the
On Wednesday, 5 September 2018 at 13:53:15 UTC, Jonathan M Davis
wrote:
Very well said, thanks.
Based on everything Walter said in the previous thread, it
honestly seems to me to be primarily like he just can't give up
on the idea that D has to worry about modeling C++ namespaces.
That is t
On Wednesday, 5 September 2018 at 08:30:25 UTC, Walter Bright
wrote:
On 9/4/2018 10:16 PM, Manu wrote:
I'm serious, you can have your cake, and potentially, I could
have my
cake too, and everybody would be happy... nobody would be sad.
If it is the same,
It is
I provided solutions in those
On Sunday, 2 September 2018 at 05:14:58 UTC, Chris M. wrote:
Hopefully that was coherent. Again this is me for me to get my
thoughts out there, but also I'm interested in what other
people think about this.
Thanks! Please add anything you think is missing to
https://github.com/dlang/dlang.org
On Saturday, 1 September 2018 at 14:48:55 UTC, Jonathan Marler
wrote:
Note that we would want this to be a new option so as not to
break anyone depending on "-op" semantics. Maybe "-om" for
"output path based on 'Module' name"?
LDC has this already as -oq, FWIW.
On Thursday, 30 August 2018 at 23:03:57 UTC, Walter Bright wrote:
On 8/25/2018 4:49 PM, Nicholas Wilson wrote:
Run semantic3 on the constructor independent of the
requirement to destruct already constructed objects. If the
constructors is nothrow then there is no need to have the
destructors r
On Wednesday, 29 August 2018 at 16:38:48 UTC, Ali Çehreli wrote:
On 08/22/2018 10:20 PM, Nicholas Wilson wrote:
That reminds me, what happened to our conversation with Ali
Çehreli about splitting general [newsgroup/forum] into
Technical and less technical?
Even I remember that conversation.
On Wednesday, 29 August 2018 at 08:35:30 UTC, Walter Bright wrote:
On 8/28/2018 10:18 PM, Nicholas Wilson wrote:
Bugzilla is not documentation. These are language changes they
need to be in release notes and the spec.
You asked for a clue: "we have no clue WTF its supposed to do
or why the ch
On Wednesday, 29 August 2018 at 05:04:22 UTC, Walter Bright wrote:
On 8/25/2018 4:09 AM, Nicholas Wilson wrote:
On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright
wrote:
I'm not hostile to debate. I just don't care for "this is
uncharted territory, so let's do nothing" which has been
g
On Tuesday, 28 August 2018 at 08:39:20 UTC, bauss wrote:
The following language is a dangerous competitor to D.
https://github.com/joaomilho/Enterprise
Thats very funny, but I found Rockstar even funnier.
On Monday, 27 August 2018 at 01:10:17 UTC, Manu wrote:
On Sun, 26 Aug 2018 at 18:08, Manu wrote:
Actually, I'm really mostly interested in DX12 shader output
right
now... I think there are tools that can convert LLVM to DX
shaders? I
haven't looked into it yet, but it's on my backlog.
Next wo
On Monday, 27 August 2018 at 00:26:35 UTC, Manu wrote:
Yeah, i've been following both those efforts.
I don't have any free time to motivate this stuff on my own
right now.
I'm just listing all the things (because Walter asked me to).
Fair enough. I suppose you'd need namespaces working first
On Sunday, 26 August 2018 at 23:39:32 UTC, Manu wrote:
We could really use robust tools to produce a matching C++ .h
file
from the extern symbols in a D module, and likewise a .di file
from a
C/C++ header.
This category of tooling has many existing instances, it's
overwhelming. As far as I can
On Sunday, 26 August 2018 at 20:55:04 UTC, Walter Bright wrote:
On 8/26/2018 12:34 PM, Manu wrote:
I work at a company with a thousand engineers, all VS users, D
could
find home there if some rough edges were polished, but they
*absolutely must be polished* before it would be taken
seriously.
On Sunday, 26 August 2018 at 10:17:51 UTC, Walter Bright wrote:
I'm not sure what you're referring to. I'm referring to the
specified message, and the example:
struct Array
{
int[] _payload;
~this() // (2)
{
import core.stdc.stdlib : free;
free(_payload.ptr); // (3)
On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
On 8/25/2018 3:52 AM, Chris wrote:
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
Every programmer who says this also demands new (and
breaking) features.
"Every programmer who..." Really?
You want to remove a
On Saturday, 25 August 2018 at 20:19:44 UTC, Walter Bright wrote:
On 8/25/2018 6:32 AM, Timon Gehr wrote:
(Or at least, not wrong. Using e.g. `void*` instead of an
incompatible type would already be an improvement.)
Making it void* is a reasonable idea.
If/when (I really hope the latter) DIP
On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright wrote:
I'm not hostile to debate. I just don't care for "this is
uncharted territory, so let's do nothing" which has been going
on for probably 4 years now, coincident with "scope is
incomplete, D sux".
I.e. lead, follow, or get out o
On Saturday, 25 August 2018 at 07:56:55 UTC, 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
constru
On Saturday, 25 August 2018 at 01:43:19 UTC, Walter Bright wrote:
On 8/24/2018 4:22 PM, tide wrote:
struct SomeStruct
{
void foo() {
// use SomeStruct
}
}
void broken()
{
void function() foo = &SomeStruct.foo;
foo(); // runtime error, isn't actually safe uses wrong
On Friday, 24 August 2018 at 09:58:13 UTC, Walter Bright wrote:
On 8/23/2018 5:02 PM, Nicholas Wilson wrote:
am currently up against a ~thousand headed hydra~ thousand
line function .
Good times :-)
Tell me about it. I'm now wading through its carcass in review. I
will split it up but it ta
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh
wrote:
How much time or money exactly has Weka spent on getting this
issue and other "critical" bugs fixed?
Weka is paying prominent D developers as contractors. We've had
David Nadlinger and currently employ Johan Engelen. Both said
On Thursday, 23 August 2018 at 07:00:01 UTC, Iain Buclaw wrote:
On Thursday, 23 August 2018 at 06:34:04 UTC, Shachar Shemesh
wrote:
On 23/08/18 09:17, Jacob Carlborg wrote:
I don't see why we just can't add support for scoped lazy
parameters. It's already in the language just with a
different
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 given up on
affecting change.
It is no sec
On Tuesday, 21 August 2018 at 14:31:02 UTC, Atila Neves wrote:
The problem is that the code we write doesn't deal directly
with pointers - see the recent confusion in this forum over
where `scope` on the left applies to the `this` pointer or the
one returned by the member function.
Kagamin ju
On Tuesday, 21 August 2018 at 10:57:15 UTC, Atila Neves wrote:
On Tuesday, 21 August 2018 at 09:50:46 UTC, Atila Neves wrote:
On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote:
On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote:
On Monday, 20 August 2018 at 12:56:42 UTC, Kagam
On Monday, 20 August 2018 at 09:31:09 UTC, Atila Neves wrote:
On Friday, 17 August 2018 at 13:39:29 UTC, Steven Schveighoffer
wrote:
// used to be scope int* ptr() { return ints; }
scope inout(int)* ptr() inout { return ints; }
Does scope apply to the return value or the `this` reference?
I
On Tuesday, 7 August 2018 at 08:20:55 UTC, Basile B. wrote:
On Tuesday, 7 August 2018 at 07:33:49 UTC, Nicholas Wilson
wrote:
so the following
void foo(As...)(As as)
in
{
static foreach (a ;as)
assert(a>0);
}
do
{
}
void main()
{
foo(1,2,3,4,5);
}
passes and compiles, whereas
void
On Friday, 10 August 2018 at 13:15:46 UTC, Dukc wrote:
The benefit would be that null can be a regular pointer
constant (enum null = typeof(&assert(false)).init) instead of a
symbol with special meaning. I'd think it makes compiler rules
less complex.
I disagree.
Another advantage is that yo
On Friday, 10 August 2018 at 11:31:02 UTC, Dukc wrote:
On Friday, 10 August 2018 at 11:28:38 UTC, Dukc wrote:
One example comes to mind: is(typeof(null) ==
typeof(assert(0))).
meant is(typeof(*null) == typeof(assert(0)))
How is that a good thing??? Also that is not specified in the
dip. I
On Thursday, 9 August 2018 at 10:47:37 UTC, Stefan Koch wrote:
Regarding the rationale:
It should be pointed out that this is a further complication of
the type-system (which is already more complex than what c++
has).
That does impact generic code.
My own experience with generic code has sh
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1017, "Add Bottom Type":
https://github.com/dlang/DIPs/blob/8274b0f600075e4553b41c31f4b77be2d917bb40/DIPs/DIP1017.md
All review-related feedback on and dis
so the following
void foo(As...)(As as)
in
{
static foreach (a ;as)
assert(a>0);
}
do
{
}
void main()
{
foo(1,2,3,4,5);
}
passes and compiles, whereas
void foo(As...)(As as)
static foreach (a ;as)
in(a>0)
{
}
void main()
{
foo(1,2,3,4,5);
}
does not compile. I suppose tha
On Tuesday, 7 August 2018 at 05:58:17 UTC, Walter Bright wrote:
On 8/6/2018 8:14 PM, Nicholas Wilson wrote:
Yes, but only for a single instance of the namespace.
In the general case no, see the first reply in
https://forum.dlang.org/post/xdaedmlbbqtztiqcw...@forum.dlang.org
The idea is to not
On Tuesday, 7 August 2018 at 02:25:32 UTC, Walter Bright wrote:
Let's see if we can find some common ground.
The boilerplate I suggested seems to enable DPP to generate
working code that behaves "as if" the namespace scope is not
there, even for nested namespaces.
Is this correct?
Yes, but
On Tuesday, 31 July 2018 at 23:02:16 UTC, Rubn wrote:
One thing I don't like is that the C++ namespaces takes the
name. So if you try to import a module that has C++ namespace
of the same with the existing module, then you'll get an error.
For effectively no reason, because as you say that name
is there any particular reason why
void foo(string a) {}
void foo(immutable(char)* b) {}
void bar()
{
foo("baz");
}
result in
Error: foo called with argument types (string) matches both:
foo(string a)
and:
foo(immutable(char)* b)
especially given the pointer overload is almost always
void
On Monday, 30 July 2018 at 02:53:43 UTC, Nicholas Wilson wrote:
On Monday, 30 July 2018 at 02:15:57 UTC, Walter Bright wrote:
On 7/29/2018 1:45 PM, Manu wrote:
There's no way you'll get a bug report from someone
complaining they
can't multiply define symbols in the same scope. That's
common se
On Monday, 30 July 2018 at 02:15:57 UTC, Walter Bright wrote:
On 7/29/2018 1:45 PM, Manu wrote:
There's no way you'll get a bug report from someone
complaining they
can't multiply define symbols in the same scope. That's common
sense.
But then you cannot interface with this C++ code:
nam
On Monday, 30 July 2018 at 02:09:37 UTC, Walter Bright wrote:
On 7/29/2018 1:52 PM, Manu wrote:
On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d
wrote:
[...]
so that a straight C++ namespace => D module hierarchy mapping
would probably be required in the general case:
```
// cppns/packag
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote:
On 7/28/2018 11:18 AM, Manu wrote:
Make a PR that implements namespace as a string... I will use
that fork of D forever.
1. Look how it is mangled on the C++ side. (Use "grep" on the
object file.)
2. Use:
pragma(mangle, "the
On Thursday, 26 July 2018 at 02:21:58 UTC, Ali Çehreli wrote:
On 07/25/2018 04:27 PM, Nicholas Wilson wrote:
On Wednesday, 25 July 2018 at 21:59:52 UTC, Ali Çehreli wrote:
Somebody had posted an article here on how well different
languages matched certain requirements of a certain coding
saf
On Wednesday, 25 July 2018 at 21:59:52 UTC, Ali Çehreli wrote:
Somebody had posted an article here on how well different
languages matched certain requirements of a certain coding
safety standards.
I remember D was doing pretty well and I think Ada (or SPARK?)
was included as well. What ar
On Saturday, 21 July 2018 at 04:09:25 UTC, Jonathan M Davis wrote:
Honestly, I think we're just coming from points of view that
are too different. IMHO, the core use case for ref is for a
function to mutate an argument and have that result progagate
to the argument,
I think the critical point
On Friday, 20 July 2018 at 23:35:46 UTC, Jonathan M Davis wrote:
On Friday, July 20, 2018 14:35:57 Manu via Digitalmars-d wrote:
Comparatively rare? It's exactly what most functions using
output ranges need to do. For many output ranges, if the
function copies the range instead of copying, then
1 - 100 of 398 matches
Mail list logo
