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
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 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 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 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 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 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 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 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 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: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 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,
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 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 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 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 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 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 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 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 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 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 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 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, 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 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
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 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/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 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 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 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 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.
On Thursday, 12 July 2018 at 21:16:02 UTC, Walter Bright wrote:
as Python's BDFL.
Don't get any ideas!
as Python's BDFL.
https://mail.python.org/pipermail/python-committers/2018-July/005664.html
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
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:
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
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
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 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 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
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
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 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
Am Thu, 12 Jul 2018 17:32:06 + schrieb Johannes Pfau:
> Am Thu, 12 Jul 2018 09:48:37 -0400 schrieb Andrei Alexandrescu:
>
>>> I agree that the current syntax is lacking. This was Andrei's
>>> proposition and I was initially against it, but he said to put it in
>>> the DIP so that we can
Am Thu, 12 Jul 2018 09:48:37 -0400 schrieb Andrei Alexandrescu:
>> I agree that the current syntax is lacking. This was Andrei's
>> proposition and I was initially against it, but he said to put it in
>> the DIP so that we can discuss it as a community. Maybe this syntax is
>> better:
>>
>>
https://issues.dlang.org/show_bug.cgi?id=19081
--- Comment #2 from Yuxuan Shui ---
This is because, at statement level, enum is also a storage class:
enum X = 10;
I wonder why declaring enum without a UDA works at statement level. I smell
terrible hacks.
--
https://issues.dlang.org/show_bug.cgi?id=19081
Yuxuan Shui changed:
What|Removed |Added
Summary|Can't declare enum with UDA |Can't declare enum with UDA
On 7/12/18 11:42 AM, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:33:03 UTC, Andrei Alexandrescu wrote:
Again: not the charter of this DIP, so you should ask yourself, not
us, this question.
Look, I understand it can be frustrating to have a concrete design
proposal derailed by a
On Wednesday, 11 July 2018 at 03:00:48 UTC, Ali wrote:
Somehow, this is the type of problem, i thought point 1 in the
vision document is aimed to solve
https://wiki.dlang.org/Vision/2018H1
"1. Lock down the language definition: D is a powerful language
but its definition is not precise
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 syscall(size_t ident, long*
arg0);
long tid;
On Thursday, 12 July 2018 at 15:42:29 UTC, Luís Marques wrote:
On Thursday, 12 July 2018 at 15:33:03 UTC, Andrei Alexandrescu
wrote:
Again: not the charter of this DIP, so you should ask
yourself, not us, this question.
Look, I understand it can be frustrating to have a concrete
design
On Thursday, 12 July 2018 at 15:33:03 UTC, Andrei Alexandrescu
wrote:
Again: not the charter of this DIP, so you should ask yourself,
not us, this question.
Look, I understand it can be frustrating to have a concrete
design proposal derailed by a myriad of speculative questions.
But if we
https://issues.dlang.org/show_bug.cgi?id=19070
--- Comment #1 from Hiroki Noda ---
Attemptive PR : https://github.com/dlang/dmd/pull/8490
--
On Thursday, 12 July 2018 at 15:34:25 UTC, Andrei Alexandrescu
wrote:
The DIP mentions the interaction of @implicit with alias this.
Not the interaction I was asking about, although admittedly it
was speculative.
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 of implicit conversions in D. In
my experience, it's not that all types need to be
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 07/12/2018 11:25 AM, Luís Marques 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 relaxed in the future in
order to
On 07/12/2018 11:22 AM, Timon Gehr wrote:
On 12.07.2018 15:29, Andrei Alexandrescu wrote:
On 07/11/2018 05:55 AM, Nick Treleaven wrote:
...
Removing `static` works. Otherwise I tried changing `ref` to `alias`:
Error: variable src cannot be read at compile time
But this shorter code seems to
On 07/12/2018 10:54 AM, Jonathan M Davis wrote:
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
On 12.07.2018 17:22, Timon Gehr wrote:
alias field0 = s.tupleof[0];
t.tupleof[0] = field0;
alias field1 = s.tupleof[1];
t.tupleof[1] = field1;
alias field2 = s.tupleof[2];
t.tupleof[2] = field2;
Error: alias `a` cannot alias an expression `tuple(s.a, s.b, s.c)[0]`
Error: alias `b` cannot alias
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 12.07.2018 15:29, Andrei Alexandrescu wrote:
On 07/11/2018 05:55 AM, Nick Treleaven wrote:
...
Removing `static` works. Otherwise I tried changing `ref` to `alias`:
Error: variable src cannot be read at compile time
But this shorter code seems to work fine:
this.tupleof = src.tupleof;
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 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
On Wednesday, 11 July 2018 at 20:38:13 UTC, Dukc wrote:
On Wednesday, 11 July 2018 at 19:41:37 UTC, Jordi Gutiérrez
Hermoso wrote:
Just getting it into -betterC territory seems like a very
daunting task.
You do not need -betterC anymore. At least the LDC frontend
will only add linking hooks
https://issues.dlang.org/show_bug.cgi?id=3567
--- Comment #9 from Steven Schveighoffer ---
I think a trait "ForceUnqual" may be needed in some cases, but "Unqual" I have
always expected to behave the way it does (except in the case of structs
containing references, for which it should not strip
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 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
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 Thursday, 12 July 2018 at 11:36:15 UTC, RhyS wrote:
Its the same with the donations. I stated before that D as a
organisation with its financing feels very mysterious. You do
not see where the money goes
I've raised this issue elsewhere. I think there would be more
incentive to donate if
I'm very happy to announce the next Seoul D meetup on August 9 at
7:00 pm. We're partnering with local company BlockchainOS and the
Meetup group 'Learn Teach Code Seoul' for an interactive
'Introduction to D' presentation/tutorial followed by an hour of
coding challenges. BlockchainOS is
https://issues.dlang.org/show_bug.cgi?id=3567
--- Comment #7 from Timoses ---
(In reply to Steven Schveighoffer from comment #6)
> I'm changing the title accordingly. Perhaps we should actually close this
> bug and open another, as the whole issue has really been flipped around?
Perhaps you're
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 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
{
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 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
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 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
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
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/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 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 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 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 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 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
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/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.
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=18979
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #1 from
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
1 - 100 of 122 matches
Mail list logo
