On Friday, 23 January 2015 at 10:31:45 UTC, aldanor wrote:
Hi all, I've started redesigning dlang.org AGAIN (yea, I
know...).
There are several issues with structure and presentation that I
think will have to be addressed. While compiling these, I also
had several people that know nothing
On Friday, 23 January 2015 at 21:56:59 UTC, H. S. Teoh wrote:
On Fri, Jan 23, 2015 at 09:20:10PM +, Zach the Mystic via
Digitalmars-d wrote:
[...]
I have a basic suggestion on how to get started. Create a
Learning D
button and put it on the menu at left on the front page. On
the page
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis
wrote:
Personally, I'd much prefer that we not make this change. It's
just
shuffling things around in an attempt to make them more
consistent while
actually making them _less_ consistent.
- Jonathan M Davis
I don't think this
On Monday, 26 January 2015 at 19:02:27 UTC, Zach the Mystic wrote:
The changes suggested in this thread are of kind 5.5.
s/5.5/B5
On Friday, 23 January 2015 at 17:03:17 UTC, aldanor wrote:
1) D Learning
This is the most problematic part. It's not even obvious where
to start.
Say I just landed on dlang.org via a google search and I want
to find a quick user guide. I click D Reference (that seems the
closest one to
On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:
Frankly, I think that is a great bikeshedding non-issue that
distracts us from what is important. I hope that by doing this
PR, we can actually decide that it isn't worth it, i.e. I'd be
happy to get consensus and revert it.
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:
I agree with Jonathan's points, this solution doesn't seem like
an improvement. If I understand the problem, we don't want to
make every attribute use the '@' symbol because it looks bad
and would cause a lot of code changes
On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler wrote:
I think the short answer is that it's WAY too complicated for
the benefit. Also, why burden the syntax highlighter, let
alone the human reader, with ambiguities like this?
I wasn't saying that we should introduce ambiguity, I
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, bool-expr) be supported though?
Yes. That's what I intended, sorry the wording
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, bool-expr) be supported though?
Yes. That's what I intended, sorry the wording
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, bool-expr) be supported though?
Yes. That's what I intended, sorry the wording
On Monday, 2 February 2015 at 20:09:42 UTC, Piotrek wrote:
On Monday, 2 February 2015 at 06:07:29 UTC, Zach the Mystic
wrote:
Therefore, I think std.experimental is for all in flux APIs,
from the drafting stage to the later less in flux stages.
Definitely this is what I thought initially.
On Monday, 2 February 2015 at 21:01:30 UTC, Johannes Pfau wrote:
Am Mon, 02 Feb 2015 12:39:28 -0500
schrieb Steven Schveighoffer schvei...@yahoo.com:
On 2/2/15 12:06 PM, Johannes Pfau wrote:
Am Mon, 02 Feb 2015 02:49:48 -0800
schrieb Walter Bright newshou...@digitalmars.com:
Please try it
On Monday, 2 February 2015 at 22:18:59 UTC, Piotrek wrote:
On Monday, 2 February 2015 at 21:19:01 UTC, Zach the Mystic
wrote:
I think std.experimental should essentially be its own
library, with its own slot next to phobos on the github repo.
I'm open to changing the name or something... but
On Friday, 6 February 2015 at 03:14:59 UTC, Walter Bright wrote:
I don't see how any proposal can work unless it specifies a
safe interface to an unsafe section of code. (I read a Rust
tutorial that rather bluntly pointed this out as well.)
Link?
On Friday, 6 February 2015 at 18:58:27 UTC, David Nadlinger wrote:
On Friday, 6 February 2015 at 17:13:09 UTC, Zach the Mystic
wrote:
It's been suggested that '@system' be used to mark the blocks
in question. The point would be to emphasize the dangerousness
of the operation. The function is
On Friday, 6 February 2015 at 17:12:40 UTC, David Nadlinger wrote:
It seems obvious that explicitly whitelisting a small number of
potentially dangerous but safe operations is much less
error-prone approach than disabling compiler checks for
everything and then having to remember to blacklist
On Friday, 6 February 2015 at 19:16:13 UTC, Andrei Alexandrescu
wrote:
This is precisely why I have lost all interest in @safe. It's
clear that
the present problematic situation will continue to hold, and
the
decision makers are not interested to address it. I am not
going to
waste any more
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
No, at least three of us, Steven, H.S. Teoh and myself have
confirmed that we've moved beyond requesting @trusted blocks.
We are no longer requesting them. We are requesting *@system*
blocks, which can only appear in @trusted
On Friday, 6 February 2015 at 21:56:40 UTC, Walter Bright wrote:
On 2/6/2015 11:29 AM, Zach the Mystic wrote:
My attitude is not based on evidence. It's based on just
thinking about the
problem:
http://forum.dlang.org/post/eeglnychgudcffpjc...@forum.dlang.org
I really can't answer this
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
This solution appeals to me greatly. It pinpoints precisely
where unsafe code can generate; it catches unintended safety
violations in all @trusted code outside @system blocks, as
requested by many people so far; it makes
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote:
This solution appeals to me greatly. It pinpoints precisely
where unsafe code
can generate; it catches unintended safety violations in all
@trusted code
outside @system blocks, as requested by many people so far; it
makes systems
On Saturday, 7 February 2015 at 01:43:01 UTC, Andrei Alexandrescu
wrote:
With the system proposal we're looking at something like:
version (Posix) void[] read(in char[] name, size_t upTo =
size_t.max) @trusted
{
import core.memory;
// A few internal configuration parameters {
enum
On Saturday, 7 February 2015 at 01:41:19 UTC, Andrei Alexandrescu
wrote:
Consider the previous code:
[...]
static trustedRead(int fildes, void* buf, size_t nbyte)
@trusted
{
return core.sys.posix.unistd.read(fildes, buf, nbyte);
}
static trustedRealloc(void* p, size_t
On Saturday, 7 February 2015 at 05:35:51 UTC, Zach the Mystic
wrote:
Note that I just mechanically your @system blocks with the
better form.
...mechanically replaced, I mean, of course.
On Saturday, 7 February 2015 at 05:35:51 UTC, Zach the Mystic
wrote:
Here's how I would rewrite what you have written using the new
method:
...
stat_t statbuf = void;
@system cenforce(trustedFstat(fd, trustedRef(statbuf)) ==
0, name);
I didn't rewrite this because I didn't see the
On Friday, 6 February 2015 at 21:33:01 UTC, Walter Bright wrote:
On 2/6/2015 10:58 AM, David Nadlinger wrote:
@trusted doesn't differ in meaning from @safe for API clients.
Both mean that
you can call the function from @safe code, nothing more,
nothing less. I hope we
agree on that.
That is
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote:
On 2/6/2015 3:02 PM, Zach the Mystic wrote:
This solution appeals to me greatly. It pinpoints precisely
where unsafe code
can generate; it catches unintended safety violations in all
@trusted code
outside @system blocks, as
On Friday, 6 February 2015 at 23:21:50 UTC, weaselcat wrote:
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic
wrote:
No, at least three of us, Steven, H.S. Teoh and myself have
confirmed that we've moved beyond requesting @trusted blocks.
We are no longer requesting them. We are
On Wednesday, 4 February 2015 at 12:02:32 UTC, Walter Bright
wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, bool-expr) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear.
As long as you're sure the pragma will never need more than three
values
On Wednesday, 4 February 2015 at 10:07:53 UTC, Don wrote:
Yes, that's true, and so my opinions should be slightly
weighted downwards. But even so, the reality is that bugfixes
cause breakages anyway. Most code that isn't actively being
maintained, is broken already. If you're an early adopter,
On Thursday, 5 February 2015 at 21:15:52 UTC, Steven
Schveighoffer wrote:
An aspect of a well-designed encapsulation is the number of
@trusted
interfaces is minimized. If you find an abstraction that has
@trusted
sprinkled liberally through it, it's an indicator of a failed
abstraction.
I
On Thursday, 5 February 2015 at 18:44:06 UTC, CraigDillabaugh
wrote:
1) All Phobos proposals must go through
std.experimental.logger
2) It must implement something generally desired in Phobos
3) Implementation is supposed to be at least stable enough to
not undergo a full rewrite after
On Thursday, 5 February 2015 at 22:08:42 UTC, CraigDillabaugh
wrote:
On Thursday, 5 February 2015 at 21:21:22 UTC, Zach the Mystic
wrote:
On Thursday, 5 February 2015 at 18:44:06 UTC, CraigDillabaugh
clip
You know, I don't even like the use of voting when it comes to
important decisions
On Thursday, 5 February 2015 at 23:35:04 UTC, Dicebot wrote:
On Thursday, 5 February 2015 at 18:23:19 UTC, Zach the Mystic
wrote:
1) All Phobos proposals must go through
std.experimental.logger
2) It must implement something generally desired in Phobos
3) Implementation is supposed to be at
On Thursday, 5 February 2015 at 14:43:40 UTC, Steven
Schveighoffer wrote:
On 2/4/15 1:46 AM, Zach the Mystic wrote:
It's a bikeshed argument, but why not:
pragma(inline, always); // warn if unable to inline
pragma(inline, never);
pragma(inline);// revert to default behavior
?
I
On Thursday, 5 February 2015 at 05:48:43 UTC, bearophile wrote:
Zach the Mystic:
I have an idea. Treat all assert statements which come before
the first non-assert statement as part of the 'in' contract.
I'm not saying the compiler has to generate a whole 'in'
function, but these asserts can
On Thursday, 5 February 2015 at 07:06:31 UTC, deadalnix wrote:
On Thursday, 5 February 2015 at 04:36:39 UTC, Zach the Mystic
wrote:
I have an idea. Treat all assert statements which come before
the first non-assert statement as part of the 'in' contract.
I'm not saying the compiler has to
On Friday, 6 February 2015 at 02:06:29 UTC, Andrei Alexandrescu
wrote:
On 2/5/15 5:53 PM, H. S. Teoh via Digitalmars-d wrote:
And while
you're at it, try reviewing a few Phobos PR's related to
std.array as
well, and observe for yourself the maintenance issues that
arise.
Again, could you
On Friday, 6 February 2015 at 16:19:26 UTC, John Colvin wrote:
On Friday, 6 February 2015 at 16:11:31 UTC, Andrei Alexandrescu
wrote:
On 2/6/15 3:57 AM, Martin Krejcirik wrote:
If I understand it correctly, Walter is against adding
trusted blocks
(trusted {...}) into @safe functions. But what
On Friday, 6 February 2015 at 17:12:40 UTC, David Nadlinger wrote:
Let's say you have a template function that accepts a range.
For performance, you want to do some of the processing in a way
that is @system, but can be verified to be correct for all
inputs in this specific case. In other
On Friday, 6 February 2015 at 17:36:27 UTC, Atila Neves wrote:
I'm trying to promote suggesting '@system' blocks instead of
'@trusted'. '@trusted' functions, but '@system' blocks - which
can only go in @trusted functions (@system block in @system
functions are redundant). It's the same
On Friday, 6 February 2015 at 18:30:03 UTC, Zach the Mystic wrote:
That might be better than using @safe inside @trusted:
@trusted void myfunc() {
//implicitly safe
...
@system { //wouldn't compile otherwise.
auto ptr = cast(ubyte*)4;
}
//implicitly safe again
}
Exactly. I think this
On Sunday, 8 February 2015 at 13:03:28 UTC, Marc Schütz wrote:
On Thursday, 5 February 2015 at 16:34:38 UTC, Zach the Mystic
wrote:
Can you name one, or even imagine one? Bear in mind people
like Andrei and myself do not like to read or write the later
form and will use it much less,
On Sunday, 8 February 2015 at 17:12:20 UTC, Daniel Murphy wrote:
Zach the Mystic wrote in message
news:qxtyqdeewrjurmwhk...@forum.dlang.org...
I don't know how the second assert could men somethign
different from the first. If you assert (anything but
assert(0)) first thing, you certainly
On Sunday, 8 February 2015 at 15:28:10 UTC, Vladimir Panteleev
wrote:
On Sunday, 8 February 2015 at 15:20:17 UTC, karl wrote:
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
If you don't want to write base twice, you can
On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu
wrote:
Please help us work the kinks out! Walter will be proceeding
with the opt-in implementation for quicker pipelining.
http://wiki.dlang.org/DIP25
Andrei
I'm working on an article/DIP which actually goes further than
the
On Friday, 16 January 2015 at 23:51:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
It may not directly impact the quality of the product, but it
*could* affect morale (potential contributor looks at the PR
list, sees it's 90+, and feels that it's unlikely his
contributions
will ever get accepted,
I've now created DIP70 for this issue:
http://wiki.dlang.org/DIP70
Maybe a more sophisticated linking mechanism will make DIP70
unnecessary, but it should fuel the discussion nonetheless. Also,
the wiki refused all of my attempts to insert the following
links, saying they were non-canonical,
On Saturday, 17 January 2015 at 17:08:42 UTC, Marc Schütz wrote:
On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic
I'm working on an article/DIP which actually goes further than
the new DIP25, but is nonetheless completely compatible with
it. I'll have the article in a day or two.
On Monday, 19 January 2015 at 01:42:58 UTC, Adam D. Ruppe wrote:
Anyone like to do a quick proofread of the next edition of This
Week in D?
float divideBy(float divisor, float dividend) {
return dividend / dividend; -- not a very interesting
mathematical operation here!
On Tuesday, 20 January 2015 at 04:03:23 UTC, Andrei Alexandrescu
wrote:
Thanks! Well it's probably time to start talking content, too.
Andrei
Quick suggestion: The twitter feed takes up more screen space
than it's worth, IMO. I think the same amount of space should be
taken up by a more
On Tuesday, 20 January 2015 at 21:42:52 UTC, Andrei Alexandrescu
wrote:
On 1/20/15 12:10 PM, Zach the Mystic wrote:
Quick suggestion: The twitter feed takes up more screen space
than it's
worth, IMO. I think the same amount of space should be taken
up by a
more general (though not explicitly
On Tuesday, 20 January 2015 at 04:03:23 UTC, Andrei Alexandrescu
wrote:
Well let be honest the site was in need of some fresh air. And
the new
menu is really good. Congratulations.
Thanks! Well it's probably time to start talking content, too.
Here's another guiding thought. The site should
On Sunday, 18 January 2015 at 18:17:17 UTC, Meta wrote:
If your function is marked as pure, then escape by global is
impossible.
Yes, I know. Only impure functions could possibly require
'noscope'. But you might access global state without writing to
it, or without copying the parameter
On Sunday, 18 January 2015 at 18:17:17 UTC, Meta wrote:
I have a lot of other thoughts about this issue, but I want to
save them for a different thread.
If your function is marked as pure, then escape by global is
impossible.
Maybe it could just be made illegal to copy *any* parameter
In general, these attributes would only appear very rarely.
http://wiki.dlang.org/DIP71
I want to keep this simple. There are three ways for a reference
passed to a function to escape that function.
static T* s;
T* fun(T* p1, T** p2) {
// escape by global
s = p1;
// escape by return
return p1;
// escape by mutable argument
*p2 = p1;
}
I like the buttons with the dark red gradients on the left.
Although the button titles don't seem professional to me, the
buttons do.
I'm personally interested in seeing the story of D told better.
I have more of a conscious opinion of the words of the front page
than I do of the
On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic wrote:
I'm working on an article/DIP which actually goes further than
the new DIP25, but is nonetheless completely compatible with
it. I'll have the article in a day or two.
Here it is:
On Sunday, 18 January 2015 at 19:05:37 UTC, Marc Schütz wrote:
Some random comments:
I like that it applies to all kinds of references, not just
`ref`. Do you want it to apply to structures with reference
members, too? What about value types in general?
I have some thoughts about `ref` that
On Thursday, 22 January 2015 at 12:04:43 UTC, Steven
Schveighoffer wrote:
It's not just old PCs. I had to up my vmware linux image's
memory from 1GB to 2GB just to compile the default vibe.d
program. This is unacceptable. I rent a VPS with minimum
memory, and I have to compile vibe.d locally
On Tuesday, 10 February 2015 at 15:49:24 UTC, Zach the Mystic
wrote:
Wait a second... you're totally right. That is a cool solution.
The only hiccup is that it might be hard to implement in the
compiler because of flow tracking (i.e. the error comes before
the @system block, forcing a recheck
On Tuesday, 10 February 2015 at 16:04:05 UTC, Marc Schütz wrote:
On Tuesday, 10 February 2015 at 15:57:28 UTC, Zach the Mystic
wrote:
On Tuesday, 10 February 2015 at 15:49:24 UTC, Zach the Mystic
wrote:
As already pointed out in the other thread, there is a
non-breaking variant of (3):
3a.
On Tuesday, 27 January 2015 at 01:31:07 UTC, Jonathan Marler
wrote:
Yes you're right it adds more inconsistency (sorry what I said
was wrong). However, no matter what solution you choose you
have to choose one of two evils. Either add inconsistency or
break code. There's no way around it.
On Tuesday, 27 January 2015 at 03:41:51 UTC, weaselcat wrote:
FYI, Qatari Airway's GCEO Al Baker has repeatedly publicly
stated his opinion(on disliking) Boeing. Both Al Jazeera and
Qatari Airway are owned by the Qatari government.
Take an entire box of salt with that documentary.
I won't.
On Tuesday, 27 January 2015 at 04:10:24 UTC, Andrei Alexandrescu
wrote:
I'm ready to commit to dfix. Problem is many of the changes
suggested are unlikely to mark much improvement, while miring
us in the perpetual illusion of making progress.
I don't think there's any illusion about D's great
On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler
wrote:
On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
3. Singularity of usage also matters. There should only be one
way to mark a given attribute, either with or without `@`.
I agree that the proposal doesn't solve
On Tuesday, 27 January 2015 at 03:33:15 UTC, Jonathan Marler
wrote:
This has come up before. I believe if was at DConf 2014 that
Walter answered this question. If I remember, the gist was that
Walter didn't like the idea that the compiler could rewrite a
user's code, he seemed kinda creeped
On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote:
On 1/26/2015 6:15 PM, Zach the Mystic wrote:
What's keeping you from committing to 'dfix' as the way to
solve issues like the
one in this thread?
Inertia of people being reluctant to use it. It's still work
for people to use,
On Tuesday, 27 January 2015 at 02:52:44 UTC, Walter Bright wrote:
On 1/26/2015 6:38 PM, Zach the Mystic wrote:
Unfortunately, even Boeing isn't what it used to be:
https://www.youtube.com/watch?v=rvkEpstd9os
One thing that one learns when working on engineering projects
is journalists have
On Monday, 26 January 2015 at 23:32:59 UTC, Jonathan Marler wrote:
Copy/Paste:
solution). By restricting the attributes to only appear
after a function signature, it would also normalize the issue
of consistent location of attributes, but this is another
debate.
The return type doesn't
On Monday, 26 January 2015 at 23:50:12 UTC, Zach the Mystic wrote:
Yes it *is* another debate. Now you can't add attributes at the
beginning:
// no can do anymore
nogc pure myUda
retType funcName() {
...
}
// must do this instead
retType funcName() nogc pure myUdal {
}
You're suggesting
On Monday, 26 January 2015 at 23:53:22 UTC, Jonathan Marler wrote:
http://en.wikipedia.org/wiki/Straw_man
I'm not proposing that we don't allow attributes before a
function, I was mentioning an idea related to my proposal. I
agree with everything you said, you're just not addressing the
On Tuesday, 27 January 2015 at 01:49:41 UTC, Walter Bright wrote:
On 1/26/2015 5:45 PM, uri wrote:
I get the impression it will never be finished because too
many are afraid of
important breaking changes that seem necessary to get through
the last 5%-10% of
D2.
Half want breaking changes,
On Tuesday, 27 January 2015 at 01:41:31 UTC, Joakim wrote:
I was just surfing reddit and this exchange with Walter made me
LOL, talking about students who learn programming for the first
time in college:
Walter: Why would you say that? Very few of them actually even
studied CS - they learned
On Wednesday, 28 January 2015 at 19:07:59 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic
wrote:
I think a keyword is a keyword is a keyword. If it's a keyword
to the right it should be one everywhere. How is somethign
that's a built-in attribute one
On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic
wrote:
It's utterly confusing is the problem. I would consider it a
great disservice to all D programmers to allow this. Just
because you can doesn't mean you
On Friday, 30 January 2015 at 20:39:27 UTC, Zach the Mystic wrote:
Somehwta related: I'm trying to create a Getting Started page
on the home site primarily to redirect newcomers to the wiki.
My skills building the homepage docs are lacking however. I
didn't want to make a new post here, but
On Thursday, 29 January 2015 at 18:24:29 UTC, Jonathan Marler
wrote:
The recent thread about how to solve the problem of odd looking
function attributes gave me an idea to have a page that
explains why certain decisions were made in the language.
Instead of having to write a long thought out
On Saturday, 24 January 2015 at 18:59:52 UTC, H. S. Teoh wrote:
On Sat, Jan 24, 2015 at 06:51:08PM +, Zach the Mystic via
Digitalmars-d wrote:
On Friday, 23 January 2015 at 21:56:59 UTC, H. S. Teoh wrote:
On Fri, Jan 23, 2015 at 09:20:10PM +, Zach the Mystic via
Digitalmars-d wrote
I'm looking for feedback for:
https://github.com/D-Programming-Language/dlang.org/pull/878
https://issues.dlang.org/show_bug.cgi?id=14088
Investigation shows that the D Wiki is the best landing place for
newcomers, so they are directed there first. I think the current
page leaves newcomers a
On Saturday, 31 January 2015 at 19:35:45 UTC, Zach the Mystic
wrote:
On Saturday, 31 January 2015 at 19:22:06 UTC, Jonathan Marler
wrote:
Seems like a good idea to me. One thought, when I'm looking
at a new language and I see a Getting Started, I would
expect to see links for tutorials such
On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote:
Hi,
The history of std.(experimental.)logger and the latest thread
about gui functionality inclusion into Phobos made me think
about how to solve the problem of adding new modules.
I came up with the idea (maybe not new) to create
On Saturday, 31 January 2015 at 19:22:06 UTC, Jonathan Marler
wrote:
On Saturday, 31 January 2015 at 19:03:55 UTC, Zach the Mystic
wrote:
I'm looking for feedback for:
https://github.com/D-Programming-Language/dlang.org/pull/878
https://issues.dlang.org/show_bug.cgi?id=14088
Investigation
On Saturday, 24 January 2015 at 18:59:52 UTC, H. S. Teoh wrote:
On Sat, Jan 24, 2015 at 06:51:08PM +, Zach the Mystic via
Digitalmars-d wrote:
Consider me destroyed! I mean to get started with it, but
it'll take a
week or so.
A week is a short time as far as D pull requests go. :-P
Also
On Saturday, 31 January 2015 at 21:05:27 UTC, Jonathan Marler
wrote:
Personally, when I get started with a new language the first
things I want are:
1. Examples (Hello World, File IO, some examples that
demonstrate what makes the language unique).
Currently on the front page, dlang.org.
2.
On Saturday, 31 January 2015 at 23:03:52 UTC, Piotrek wrote:
On Saturday, 31 January 2015 at 20:34:32 UTC, Zach the Mystic
wrote:
The most important thing about a standard library is
decisiveness in the leadership about what *kinds* of things
should be in it. When it's been made clear that a
On Sunday, 1 February 2015 at 23:41:22 UTC, Andrei Alexandrescu
wrote:
There's something we need to explain about the vision document
itself. Do I want to see more of Mike's awesome work in D going
forward? Yes. Do I want to see D on mobile? Of course. There's
a lot of stuff that Walter and I
On Sunday, 1 February 2015 at 22:54:51 UTC, Piotrek wrote:
On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote:
1) what would it give over std.experimental ?
- draft modules will be more flexible for changes than in the
ones in standard library
- new drafting modules won't disturb
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:
The lexer would recognize these attributes as normal ID tokens.
The grammar could be amended to allow a function to be
decorated with keywords and generic id tokens. Then the
meaning of those tokens would be handled by
On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler
wrote:
Haha, ok, sorry for being too abstract.
I think a safe way to implement my proposal would be to do what
c++ did and only allow non-keyword function attributes to omit
the '@' symbol if they appear after the function
On Tuesday, 27 January 2015 at 09:20:51 UTC, ketmar wrote:
i believe in D too, and i want it to succeed -- not only for
me. that's
why i'm writing here. i'm not attacking it for the sake of
attack, and i
deliberately took the position of outcast.
Strategically, what has your outcast position
On Tuesday, 27 January 2015 at 10:37:37 UTC, Jacob Carlborg wrote:
Seems overly complicated. How about the compiler just outputs
new files instead.
The thing I care about is that the compiler leaves the user with
no doubt as to what he should do next and how to automatically
fix his
On Monday, 26 January 2015 at 19:50:39 UTC, H. S. Teoh wrote:
If it takes just as much effort to get it into std.experimental
as it
would take to get into std directly, I don't see the point of
the
additional hassle introduced by std.experimental.
T
I agree - be shameless with what you put
On Wednesday, 28 January 2015 at 00:21:58 UTC, Vladimir Panteleev
wrote:
On Tuesday, 27 January 2015 at 18:10:10 UTC, Jonathan Marler
wrote:
Would people want and use a website that tracks who's working
on what in the D Programming Language?
Somewhat related, there's this page on the wiki:
On Wednesday, 28 January 2015 at 08:32:33 UTC, Walter Bright
wrote:
On 1/28/2015 12:02 AM, deadalnix wrote:
On Wednesday, 28 January 2015 at 07:55:22 UTC, Walter Bright
wrote:
On 1/27/2015 8:57 PM, deadalnix wrote:
For ref return, we can still
make it safe by defining the lifetime of the ref
On Wednesday, 28 January 2015 at 18:37:48 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei
Alexandrescu wrote:
On 1/28/15 10:19 AM, Jonathan Marler wrote:
On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
On Wednesday, 28 January 2015 at 17:41:54 UTC,
On Sunday, 4 January 2015 at 01:12:14 UTC, Manu via Digitalmars-d
wrote:
It's like this: ref is a massive problem when it finds it's way
into meta.
ref is relatively rare today... so the problem is occasional.
scope on the other hand will be epic compared to ref. If we
infer
scope (which we'll
1 - 100 of 245 matches
Mail list logo
