On 07/12/2018 03:40 PM, Andrei Alexandrescu wrote:
On 07/10/2018 04:58 PM, Manu wrote:
[...]
1. Explain the need and reasoning behind `@implicit`.
Razvan: I think it would help to explain that the attribute is necessary
to avoid changing semantics of existing code. Thanks.
You're still
On Wed, 11 Jul 2018 at 23:55, RazvanN via Digitalmars-d
wrote:
>
> > What's wrong with:
> > struct S {
> > this(ref S copyFrom);
> > }
> >
> > That looks like a perfectly good copy constructor declaration
> > ;) I'm just saying, the DIP needs to explain this.
>
> That is actually a valid
On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:
Consider a D REPL session like this:
void bar(long x) { writeln(x); }
void foo() { bar(42); }
42
void bar(int) {}
Assuming implementation complexity is not an issue, what do you
feel is the more natural semantics for a
I am trying to make use of the Orange package, I added the latest
version from dub to my project: "orange": "~>1.0.0" and copy
pasted the "simple usage" code from
https://github.com/jacob-carlborg/orange , but I am getting a
long list of errors:
Consider a D REPL session like this:
void bar(long x) { writeln(x); }
void foo() { bar(42); }
42
void bar(int) {}
Assuming implementation complexity is not an issue, what do you
feel is the more natural semantics for a REPL? Should foo now
call bar(int), or should it still call
On Thursday, 12 July 2018 at 15:45:41 UTC, Joakim wrote:
On Thursday, 12 July 2018 at 13:55:58 UTC, Brian wrote:
the code is error:
extern (C) nothrow @nogc size_t syscall(size_t ident);
extern (C) nothrow @nogc size_t syscall(size_t ident, size_t
arg0);
extern (C) nothrow @nogc size_t
On Thursday, 12 July 2018 at 21:16:02 UTC, Walter Bright wrote:
as Python's BDFL.
Don't get any ideas!
On Thursday, 12 July 2018 at 20:33:04 UTC, jmh530 wrote:
On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:
Most REPLs I've used are for languages with dynamic typing.
Perhaps take a look at a C REPL and see what it does?
Well, cling calls the original function:
[cling]$ #import
as Python's BDFL.
https://mail.python.org/pipermail/python-committers/2018-July/005664.html
On Thursday, 12 July 2018 at 14:13:25 UTC, Chris M. wrote:
On Wednesday, 11 July 2018 at 22:59:50 UTC, xray wrote:
The message above is repost of :
https://forum.dlang.org/post/pfjotkcazuiuhlvzi...@forum.dlang.org
So I can reply to Chris M. here.
https://issues.dlang.org/show_bug.cgi?id=18955
--- Comment #3 from Manu ---
I'm sorry. I think I must have cut fail-ed. Remove the `Alloc` arg:
---
extern (C++, std)
{
struct char_traits(Char)
{
}
extern (C++, class) struct
On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:
Assuming implementation complexity is not an issue, what do you
feel is the more natural semantics for a REPL? Should foo now
call bar(int), or should it still call bar(long)? (feel free to
generalize the issue)
BTW, this
the following seems like a easy enough workaround:
just add
` if(this is typeof(this).init) return;` at 1st line of your invariant:
```d
import std.typecons;
import std.range;
struct MyDomainData {
string username;
this(string username) @safe
in(!username.empty)
do {
On Thursday, 12 July 2018 at 21:15:46 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 20:33:04 UTC, jmh530 wrote:
On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:
Most REPLs I've used are for languages with dynamic typing.
Perhaps take a look at a C REPL and see what it
On Thursday, 12 July 2018 at 21:15:46 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 20:33:04 UTC, jmh530 wrote:
On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:
Most REPLs I've used are for languages with dynamic typing.
Perhaps take a look at a C REPL and see what it
On Thu, Jul 12, 2018 at 03:28:00PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/12/2018 2:22 PM, Luís Marques wrote:
> > On Thursday, 12 July 2018 at 21:16:02 UTC, Walter Bright wrote:
> > > as Python's BDFL.
> >
> > Don't get any ideas!
>
> I have no plans to resign until they carry me
On Thursday, 12 July 2018 at 21:16:02 UTC, Walter Bright wrote:
as Python's BDFL.
https://mail.python.org/pipermail/python-committers/2018-July/005664.html
There is controversy surrounding his opinions? I am out of the
loop here.
-Alex
On Thursday, 12 July 2018 at 22:28:00 UTC, Walter Bright wrote:
I have no plans to resign until they carry me out in a box.
That can be arranged.
(lol you guys we should carry walter out of to the stage of the
next dconf in a box)
On 7/12/18 7:15 PM, Manu wrote:
On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d
wrote:
On 07/12/2018 11:14 AM, Luís Marques wrote:
On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
When designing D libraries than lean towards DSL style, I've
frequently felt
On 7/12/18 6:34 PM, Manu wrote:
On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d
wrote:
On 07/11/2018 11:11 AM, Atila Neves wrote:
On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
But there's a super explicit `@implicit` thing written right there...
so should we
On 7/12/18 6:37 PM, Manu wrote:
On Thu, 12 Jul 2018 at 07:15, Andrei Alexandrescu via Digitalmars-d
wrote:
On 07/12/2018 09:49 AM, Atila Neves wrote:
On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
[...]
If by "come in pairs" you mean that you can define them both, then yes,
https://issues.dlang.org/show_bug.cgi?id=19065
Ali Ak changed:
What|Removed |Added
CC||ali.akhtarz...@gmail.com
--- Comment #4 from Ali
On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d
wrote:
>
> Hi everyone!
>
> I managed to put together a first draft of the DIP for adding the
> copy constructor to the language [1]. If anyone is interested,
> please take a look. Suggestions and comments about technical
> aspects and
On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/12/2018 11:14 AM, Luís Marques wrote:
> > On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
> >> When designing D libraries than lean towards DSL style, I've
> >> frequently felt impaired by the lack
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
That would work, it's just a really horrible hack and I hate it.
Bastiaan's solution to simply change the default value slipped my
mind but is really cleaner and in the same line of thought.
We're constructing a fictitious
On Thursday, 12 July 2018 at 22:24:19 UTC, Luís Marques wrote:
Right. Hopefully there aren't too many weird cases once that is
generalized to other corners of the language. I also never used
REPLs for major development, only for debugging and minor
tests, so I don't have experience with that
On Thu., 12 Jul. 2018, 7:10 pm Andrei Alexandrescu via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On 7/12/18 7:15 PM, Manu wrote:
> > On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d
> > wrote:
> >>
> >> On 07/12/2018 11:14 AM, Luís Marques wrote:
> >>> On
On Thursday, 12 July 2018 at 20:19:17 UTC, Brian wrote:
freebsd syscall()
https://www.freebsd.org/cgi/man.cgi?query=syscall=2
How to define it in D?
It should be fine like this:
extern (C) nothrow @nogc size_t syscall(size_t ident, ...);
On Thursday, 12 July 2018 at 21:51:18 UTC, aliak wrote:
Cool, is there on going work to sprucing up the D repl in the
dlang-community repo or is this a new attempt? Either way if
something is happening here then awesome!
Ah, that explains why my clone of drepl didn't compile: it was
the
On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/11/2018 11:11 AM, Atila Neves wrote:
> > On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
> >>> But there's a super explicit `@implicit` thing written right there...
> >>> so should we expect that an
On Friday, 13 July 2018 at 02:32:59 UTC, Manu wrote:
Seriously, if I was making this proposal to you, and you were
in my
position... there is no way in hell that you'd allow any of us
to slip
something so substantial by like that with the wave of a hand.
This DIP depends on @implicit. How can
On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/11/2018 11:11 AM, Atila Neves wrote:
> > On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
> >>> But there's a super explicit `@implicit` thing written right there...
> >>> so should we expect that an
On 7/12/2018 2:22 PM, Luís Marques wrote:
On Thursday, 12 July 2018 at 21:16:02 UTC, Walter Bright wrote:
as Python's BDFL.
Don't get any ideas!
I have no plans to resign until they carry me out in a box.
On Thu, 12 Jul 2018 at 06:45, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/10/2018 06:50 PM, Manu wrote:
> > On Tue, 10 Jul 2018 at 15:23, Jonathan M Davis via Digitalmars-d
> > wrote:
> >>
> >> On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digitalmars-d wrote:
> >>> 2. It looks like
On 7/12/18 4:29 PM, Manu wrote:
Being able to implement them both independently is*occasionally*
useful, but 95% of the time, destruct + copy-construct is an equally
efficient implementation for assignment. I'd suggest that this
destruct+copy-construct pattern is a perfectly good substitute for
On Thu, 12 Jul 2018 at 18:25, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 7/12/18 4:29 PM, Manu wrote:
> > Being able to implement them both independently is*occasionally*
> > useful, but 95% of the time, destruct + copy-construct is an equally
> > efficient implementation for assignment.
On 7/12/18 10:05 PM, Manu wrote:
On Thu, 12 Jul 2018 at 18:25, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/12/18 4:29 PM, Manu wrote:
Being able to implement them both independently is*occasionally*
useful, but 95% of the time, destruct + copy-construct is an equally
efficient
On Thursday, 12 July 2018 at 22:17:29 UTC, Luís Marques wrote:
I actually never tried the existing REPLs, what are your issues
with them?
No Windows support.
For drepl:
"Works on any OS with full shared library support by DMD
(currently linux, OSX, and FreeBSD)."
On Thursday, 12 July 2018 at 21:16:02 UTC, Walter Bright wrote:
as Python's BDFL.
https://mail.python.org/pipermail/python-committers/2018-July/005664.html
I looked up PEP 572 and... *this* is what people are up in arms
about? Assignment in expressions, which works fine the majority
of the
On 7/12/18 2:30 PM, ag0aep6g wrote:
On 07/12/2018 03:40 PM, Andrei Alexandrescu wrote:
On 07/10/2018 04:58 PM, Manu wrote:
[...]
1. Explain the need and reasoning behind `@implicit`.
Razvan: I think it would help to explain that the attribute is
necessary to avoid changing semantics of
On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 7/12/18 6:34 PM, Manu wrote:
> > On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d
> > wrote:
> >>
> >> On 07/11/2018 11:11 AM, Atila Neves wrote:
> >>> On Wednesday, 11 July 2018 at 07:40:32 UTC,
On Thursday, 12 July 2018 at 22:04:39 UTC, jmh530 wrote:
I think the mental model of someone coming from a dynamic
language would be as if bar is dynamically re-compiled when the
foo(int x) is entered.
Right. Hopefully there aren't too many weird cases once that is
generalized to other
On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:
Consider a D REPL session like this:
Unlike cling, drepl doesn't seem to support overloading:
Welcome to D REPL.
D> import std.stdio;
std
D> void bar(long) { writeln("long"); }
bar
D> void bar(int) { writeln("int"); }
bar
D>
On Thu, 12 Jul 2018 at 07:15, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> On 07/12/2018 09:49 AM, Atila Neves wrote:
> > On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
> >
> >> [...]
> >
> >> If by "come in pairs" you mean that you can define them both, then yes,
> >> that is the
On Thu, 12 Jul 2018 at 08:30, Luís Marques via Digitalmars-d
wrote:
>
> On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
> > More details. The DIP says:
> >
> > "The structName type needs to be identical to typeof(this); an
> > error is issued otherwise. This requirement may be
On Thu, 12 Jul 2018 at 20:15, Meta via Digitalmars-d
wrote:
>
> On Friday, 13 July 2018 at 02:32:59 UTC, Manu wrote:
> > Seriously, if I was making this proposal to you, and you were
> > in my
> > position... there is no way in hell that you'd allow any of us
> > to slip
> > something so
On Thursday, 12 July 2018 at 20:44:43 UTC, JN wrote:
I am trying to make use of the Orange package, I added the
latest version from dub to my project: "orange": "~>1.0.0" and
copy pasted the "simple usage" code from
https://github.com/jacob-carlborg/orange , but I am getting a
long list of
On Friday, 13 July 2018 at 05:29:58 UTC, Timoses wrote:
On Thursday, 12 July 2018 at 20:44:43 UTC, JN wrote:
I am trying to make use of the Orange package, I added the
latest version from dub to my project: "orange": "~>1.0.0" and
copy pasted the "simple usage" code from
https://issues.dlang.org/show_bug.cgi?id=19078
Issue ID: 19078
Summary: dmd does not remove inlined functions
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
On Wednesday, 11 July 2018 at 10:43:40 UTC, FeepingCreature wrote:
Destructors are not called for fields embedded in unions.
On the one hand this is a horrible, horrible hack. On the
other, whee!
Not only a horrible hack, but a bug, and something you really
can't rely on working in the
https://issues.dlang.org/show_bug.cgi?id=19079
Issue ID: 19079
Summary: Destructors not called in named unions
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
On Wednesday, 11 July 2018 at 20:10:17 UTC, Meta wrote:
I hate to say I told you so, but...
https://github.com/dlang/phobos/pull/5855#issuecomment-345783238
Just joking, of course =)
Nullable has needed to be completely overhauled for a long time
because it was only really designed with POD
What's wrong with:
struct S {
this(ref S copyFrom);
}
That looks like a perfectly good copy constructor declaration
;) I'm just saying, the DIP needs to explain this.
That is actually a valid constructor, according to today's
compiler. There
might be code out there that uses this syntax
On Tuesday, 10 July 2018 at 14:34:55 UTC, Timoses wrote:
`Unqual` in this case just turns `inout(int[])` into
`inout(int)[]`, which is why it complains. That's a side effect
of this example [...]
See also:
https://issues.dlang.org/show_bug.cgi?id=3567
That's my point; so this is a compile error then:
S b = S(a); // <- explicit construction of copy? ie, explicit
call to
stated `@implicit` function
Consider this code:
import std.stdio : writeln;
struct S
{
this(this)
{
writeln("postblit");
}
int a;
this(int a)
https://issues.dlang.org/show_bug.cgi?id=19076
--- Comment #8 from RazvanN ---
(In reply to kntroh from comment #7)
> (In reply to Basile B. from comment #5)
> > sorry kntroh, i've been misleaded it was so similar.
> It's nothing :).
> Thanks for the quick fix!
Don't mention it!
--
https://issues.dlang.org/show_bug.cgi?id=3567
Timoses changed:
What|Removed |Added
CC||timos...@gmail.com
--- Comment #5 from Timoses
https://issues.dlang.org/show_bug.cgi?id=8338
Timoses changed:
What|Removed |Added
CC||timos...@gmail.com
--- Comment #7 from Timoses
On Wednesday, 11 July 2018 at 12:55:35 UTC, Timoses wrote:
On Tuesday, 10 July 2018 at 18:01:59 UTC, Steven Schveighoffer
wrote:
You are overthinking :) inout typically is much easier than
you expect, until you need to create temporary structs or
types with inout members, then it becomes
On Wednesday, 11 July 2018 at 21:42:45 UTC, yannick wrote:
Hi All,
Since i'll be leaving Tamedia (who sponsored development of
Asdf) and it's not under active use anymore here we decided to
donate it to libmir.
Asdf has a few nifty features that make it perfect for reading
large amounts of
https://issues.dlang.org/show_bug.cgi?id=19080
Issue ID: 19080
Summary: Order of overloads affects the chosen method
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
On 7/10/18 6:59 PM, Jonathan M Davis wrote:
On Tuesday, 10 July 2018 16:48:41 MDT Steven Schveighoffer via Digitalmars-d
wrote:
On 7/10/18 6:26 PM, Jonathan M Davis wrote:
On Tuesday, 10 July 2018 13:21:28 MDT Timon Gehr via Digitalmars-d
wrote:
On 03.07.2018 06:54, Walter Bright wrote:
...
On 07/11/2018 05:55 AM, Nick Treleaven wrote:
On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
[1] https://github.com/dlang/DIPs/pull/129
Thanks for making the DIP. I can't get this code to compile (my struct
has an `int i` field):
static foreach (i, ref field; src.tupleof)
On 07/10/2018 04:58 PM, Manu wrote:
On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d
wrote:
Hi everyone!
I managed to put together a first draft of the DIP for adding the
copy constructor to the language [1]. If anyone is interested,
please take a look. Suggestions and comments about
On 07/11/2018 12:19 PM, vit wrote:
On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
But there's a super explicit `@implicit` thing written right there...
so should we expect that an *explicit* call to the copy constructor
is not allowed? Or maybe it is allowed and `@implicit` is a
On 07/11/2018 05:28 PM, Manu wrote:
What's wrong with:
struct S {
this(ref S copyFrom);
}
That looks like a perfectly good copy constructor declaration ;)
I'm just saying, the DIP needs to explain this.
Thanks, worth a paragraph discussing silent semantics change.
Right. This is all
You can define a struct subtype hierarchy by adding alias this
declarations to each struct. Like this:
S3 <: S2 <: S1
struct S3 { auto toS2() { return S2(); } alias toS2 this; }
etc.
You can also define a class subtype hierarchy by using class
inheritance:
C3 <: C2 <: C1
On 07/12/2018 02:54 AM, RazvanN wrote:
What's wrong with:
struct S {
this(ref S copyFrom);
}
That looks like a perfectly good copy constructor declaration ;) I'm
just saying, the DIP needs to explain this.
That is actually a valid constructor, according to today's compiler. There
might be
On 07/11/2018 11:11 AM, Atila Neves wrote:
On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
But there's a super explicit `@implicit` thing written right there...
so should we expect that an *explicit* call to the copy constructor
is not allowed? Or maybe it is allowed and `@implicit`
On 07/12/2018 09:49 AM, Atila Neves wrote:
On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
[...]
If by "come in pairs" you mean that you can define them both, then yes,
that is the case. Will add a paragraph in the DIP to specify this.
You mentioned that it's terrible that the
https://issues.dlang.org/show_bug.cgi?id=3567
Steven Schveighoffer changed:
What|Removed |Added
Summary|std.traits: Unqual doesn't |std.traits: Unqual strips
On 7/10/18 2:37 AM, Walter Bright wrote:
On 7/9/2018 6:50 PM, John Carter wrote:
Nothing creates flaky and unreliable systems more than allowing them
to wobble on past the first point where you already know that things
are wrong.
Things got so bad with real mode DOS development that I
On 07/10/2018 06:50 PM, Manu wrote:
On Tue, 10 Jul 2018 at 15:23, Jonathan M Davis via Digitalmars-d
wrote:
On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digitalmars-d wrote:
2. It looks like copy constructors are used to perform assignments
(and not constructions)... but, there is also
On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
[...]
If by "come in pairs" you mean that you can define them both,
then yes,
that is the case. Will add a paragraph in the DIP to specify
this.
You mentioned that it's terrible that the assignment operator
and the copy constructor
the code is error:
extern (C) nothrow @nogc size_t syscall(size_t ident);
extern (C) nothrow @nogc size_t syscall(size_t ident, size_t
arg0);
extern (C) nothrow @nogc size_t syscall(size_t ident, long* arg0);
long tid;
syscall(SYS_thr_self, );
writeln(tid);
Error: Function type does not match
On 7/12/18 4:58 AM, Timoses wrote:
On Tuesday, 10 July 2018 at 14:34:55 UTC, Timoses wrote:
`Unqual` in this case just turns `inout(int[])` into `inout(int)[]`,
which is why it complains. That's a side effect of this example [...]
See also:
https://issues.dlang.org/show_bug.cgi?id=3567
On Wednesday, 11 July 2018 at 22:59:50 UTC, xray wrote:
The message above is repost of :
https://forum.dlang.org/post/pfjotkcazuiuhlvzi...@forum.dlang.org
So I can reply to Chris M. here.
--
Yes, Chris, I got inspired by Rust :)
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
On Wednesday, 11 July 2018 at 21:42:45 UTC, yannick wrote:
Hi All,
Since i'll be leaving Tamedia (who sponsored development of
Asdf) and it's not under active use anymore here we decided to
donate it to libmir.
...
cheers,
y
Thanks for keeping it alive. I've used asdf at work last week
On Tuesday, 10 July 2018 at 17:25:11 UTC, Yuxuan Shui wrote:
(Although I don't quite agree with you. Some people DO resist
change, that's why some decades old languages are still
popular. But look at the popularity of new languages like Go,
and Rust, and the ever-change landscape of front-end
On Wednesday, 11 July 2018 23:39:49 MDT Walter Bright via Digitalmars-d
wrote:
> On 7/11/2018 6:54 PM, Brad Roberts wrote:
> > Anyway, this is one of the areas where people clearly have different
> > philosophies and changing minds is unlikely to happen.
>
> True, but that doesn't mean each
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)
###
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
https://issues.dlang.org/show_bug.cgi?id=18955
Mike Franklin changed:
What|Removed |Added
CC||slavo5...@yahoo.com
--- Comment #2 from
On Wednesday, 11 July 2018 at 21:19:18 UTC, Ecstatic Coder wrote:
I agree. And I must admit that from that point of view I'm
indeed part of the problem...
Its a problem every open source project faces. No matter if its D
or Crystal or ...
The main issue is that many people in those open
On Thursday, 12 July 2018 at 08:54:17 UTC, Simen Kjærås wrote:
Whether that means it's undefined behavior or the compiler
should statically disallow it is up for debate, I guess.
--
Simen
Honestly, half the reason I'm using it so enthusiastically is
that I want to emphasize that this is
https://issues.dlang.org/show_bug.cgi?id=19080
--- Comment #1 from RazvanN ---
(In reply to RazvanN from comment #0)
> //a.d
> struct Foo
> {
> private void fun(A)(A a) {}
> void fun(int a) {}
> }
>
> struct Bar
> {
> void fun(int a) {}
> private void fun(A)(A a) {}
> }
>
> //
On Tuesday, 10 July 2018 at 10:48:30 UTC, bauss wrote:
On Friday, 6 July 2018 at 23:27:57 UTC, RhyS wrote:
Total 1336 packages found.
3359 total shards
D has had a major release.
Crystal has had a minor release.
Total 1339 packages
3382 total shards
This is a really weak point,
https://issues.dlang.org/show_bug.cgi?id=18979
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #1 from
On 7/11/18 8:55 AM, Timoses wrote:
On Tuesday, 10 July 2018 at 18:01:59 UTC, Steven Schveighoffer wrote:
You are overthinking :) inout typically is much easier than you
expect, until you need to create temporary structs or types with inout
members, then it becomes problematic.
https://issues.dlang.org/show_bug.cgi?id=19059
--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd
https://github.com/dlang/dmd/commit/90ab1b325f26d08bd770cd9fd44bed085c775ad9
Fix Issue 19059 - Disallow `08` and `09` in integer literal
On Thursday, 12 July 2018 07:45:30 MDT Andrei Alexandrescu via Digitalmars-d
wrote:
> > I also very much dislike the syntax - it makes no sense to me at all. I
> > commented on the PR itself asking why it differs so much from C++ -
> > specifically, what's bad about the C++ way of doing things
On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
I managed to put together a first draft of the DIP for adding
the copy constructor to the language [1]. If anyone is
interested, please take a look. Suggestions and comments about
technical aspects and wording are all welcome.
When
https://issues.dlang.org/show_bug.cgi?id=3567
--- Comment #8 from Timoses ---
(In reply to Steven Schveighoffer from comment #6)
> Note, the bug here in FeepingCreature's case is that it strips more than it
> should. It is supposed to be safe to use Unqual.
>
> So the expectation that Unqual
On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
When designing D libraries than lean towards DSL style, I've
frequently felt impaired by the lack of implicit conversions in
D. In my experience, it's not that all types need to be
implicitly convertible to other types. Just being
https://issues.dlang.org/show_bug.cgi?id=19081
Issue ID: 19081
Summary: Can't declare enum with UDA in unittest blocks
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
On Thursday, 12 July 2018 at 15:25:10 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
BTW: Multiple alias this is still planned for inclusion in D,
right? If so, what would be the (pratical?) difference between
having copy ctors with such a relaxed type
On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
More details. The DIP says:
"The structName type needs to be identical to typeof(this); an
error is issued otherwise. This requirement may be relaxed in
the future in order to accomodate copying from objects of a
different type"
On 07/12/2018 11:29 AM, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:25:10 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
BTW: Multiple alias this is still planned for inclusion in D, right?
If so, what would be the (pratical?) difference between
On Thursday, 12 July 2018 at 12:22:34 UTC, Steven Schveighoffer
wrote:
On 7/11/18 8:55 AM, Timoses wrote:
class TestA(T : T[])
{
Test!T[] arr;
// ERROR: Can't initialize inout variable in
a for loop...
this(inout(T[]) arr) inout
{
1 - 100 of 122 matches
Mail list logo
