On Sunday, 28 August 2016 at 07:43:47 UTC, Walter Bright wrote:
You've had a couple of worthwhile posts, you're welcome to stay
and continue in that vein. Posts with unprofessional behavior,
politics, etc., will be simply deleted.
D deserved someone better than a person like Andrei, but it
On 8/28/2016 3:39 AM, Dicebot wrote:
There have never been a single professional or at least constructively fashioned
post from that account and tolerating that harms D public image. I have learned
not to argue about this but I am very unhappy that you not only allow but
encourage both off-topic
On Saturday, 27 August 2016 at 20:54:02 UTC, Walter Bright wrote:
On 8/27/2016 9:04 AM, Dicebot wrote:
Please never reply to that person unless you are his other
account. Not in an
announce threads at least.
If the post is reasonably professional, it's ok to. Abusive
posts just get deleted.
On 8/27/2016 11:58 PM, Bill Hicks wrote:
white men
There are plenty of other forums for politics. Not this one.
You've had a couple of worthwhile posts, you're welcome to stay and continue in
that vein. Posts with unprofessional behavior, politics, etc., will be simply
deleted.
On Saturday, 27 August 2016 at 20:47:16 UTC, Walter Bright wrote:
On 8/27/2016 8:19 AM, Bill Hicks wrote:
I believe Andrei's point was that Rust had focused on one
problem to the relative exclusion of others, not that memory
safety was unimportant. Rust, to its credit, has changed the
percept
On Saturday, 27 August 2016 at 15:34:04 UTC, Anonymouse wrote:
On Saturday, 27 August 2016 at 15:19:40 UTC, Bill Hicks wrote:
On Saturday, 27 August 2016 at 05:57:25 UTC, Walter Bright
wrote:
We've never mocked Rust's safety features, although I have
posted that they are too complex for D and
On Saturday, 27 August 2016 at 16:04:34 UTC, Dicebot wrote:
On Saturday, 27 August 2016 at 15:34:04 UTC, Anonymouse wrote:
...
Please never reply to that person unless you are his other
account. Not in an announce threads at least.
I ran a quick linguistic analysis and it shows that there i
On 8/27/2016 9:04 AM, Dicebot wrote:
Please never reply to that person unless you are his other account. Not in an
announce threads at least.
If the post is reasonably professional, it's ok to. Abusive posts just get
deleted.
Best to add him to your killfile instead of responding.
On 8/27/2016 8:19 AM, Bill Hicks wrote:
I believe Andrei's point was that Rust had focused on one problem to the
relative exclusion of others, not that memory safety was unimportant. Rust, to
its credit, has changed the perception of the importance of memory safety.
I bet in a few years we'
On Saturday, 27 August 2016 at 15:34:04 UTC, Anonymouse wrote:
...
Please never reply to that person unless you are his other
account. Not in an announce threads at least.
On Saturday, 27 August 2016 at 15:19:40 UTC, Bill Hicks wrote:
On Saturday, 27 August 2016 at 05:57:25 UTC, Walter Bright
wrote:
We've never mocked Rust's safety features, although I have
posted that they are too complex for D and desire a simpler
system.
"A disharmonic personality. Readi
On Saturday, 27 August 2016 at 05:57:25 UTC, Walter Bright wrote:
We've never mocked Rust's safety features, although I have
posted that they are too complex for D and desire a simpler
system.
"A disharmonic personality. Reading any amount of Rust code
evokes the joke 'friends don't let f
On Saturday, 27 August 2016 at 06:37:58 UTC, Andrej Mitrovic
wrote:
On 8/21/16, Dicebot via Digitalmars-d-announce
wrote:
This week I had a tele-meeting with Andrei and Walter regarding
the fate
of DIP1000
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)
Trivia question: why is it
On 8/21/16, Dicebot via Digitalmars-d-announce
wrote:
> This week I had a tele-meeting with Andrei and Walter regarding
> the fate
> of DIP1000
> (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)
Trivia question: why is it named DIP 1000? We've had less than 100
DIPs before https://gith
On 8/26/2016 9:53 PM, Bill Hicks wrote:
On Wednesday, 24 August 2016 at 15:30:34 UTC, Martin Nowak wrote:
we want memory safe code w/o the GC.
-Martin
Rust has had that since day one. Funny how not too long ago D core was mocking
Rust,
We've never mocked Rust's safety features, although I
On Wednesday, 24 August 2016 at 15:30:34 UTC, Martin Nowak wrote:
we want memory safe code w/o the GC.
-Martin
Rust has had that since day one. Funny how not too long ago D
core was mocking Rust, but now they're trying to be more like it.
I bet in a few years we'll see hygienic macro syst
On Tuesday, 23 August 2016 at 18:37:46 UTC, Dicebot wrote:
By its design definition DIP process is for approving
communitty proposals by Walter/Andrei thus there is no point in
pretending they can't ignore the feedback. Only reason it is
even processed in the same queue is so that developers ca
On 08/22/2016 09:44 AM, Jacob Carlborg wrote:
> It would be nice to have the whole picture now, before implementing
> DIP1000. Then it's possible to review them together, making sure the end
> goal is actual possible to achieve. Now we just have to trust Andrei and
> Walter that all features will c
On 08/22/2016 12:46 AM, John Colvin wrote:
> On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:
>> - scope is @safe only
>
> Why? I might have @system code that could still benefit from scope.
Because it can't provide expected guarantees within feature set allowed
by @system - it is too pe
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote:
It would be nice to have the whole picture now, before
implementing DIP1000.
It can be reviewed after the spec is inferred from
implementation. But yes, it can be unclear how the implementation
can affect the review process.
Do
On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote:
It would be nice to have the whole picture now, before
implementing DIP1000. Then it's possible to review them
together, making sure the end goal is actual possible to
achieve. Now we just have to trust Andrei and Walter that all
On 2016-08-21 22:01, Dicebot wrote:
This week I had a tele-meeting with Andrei and Walter regarding the fate
of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)
and intented way to move forward with it. This is a short summary of the
meeting.
Approval of DIP1000
--
On 8/21/2016 7:01 PM, Jonathan M Davis via Digitalmars-d-announce wrote:
Well, if you typically try and restrict your @system code to small parts of
your program and use @trusted to turn them into @safe, then the vast
majority of your program will be @safe. As I understand it, that's at least
how
On Sunday, August 21, 2016 21:52:59 John Colvin via Digitalmars-d-announce
wrote:
> On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote:
> > On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:
> >> - scope is @safe only
> >
> > Why? I might have @system code that could still benefit
On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote:
On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:
- scope is @safe only
Why? I might have @system code that could still benefit from
scope.
I guess it would be too restrictive, but I'm just a bit
frustrated at having to
On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:
- scope is @safe only
Why? I might have @system code that could still benefit from
scope.
27 matches
Mail list logo
