On Tuesday, 9 December 2014 at 20:19:59 UTC, H. S. Teoh via
Digitalmars-d wrote:
I don't see what's the problem with making it an empty
template. It
eliminates dead code in your executable if you never call that
function,
it enables attribute inference, and it allows inlining. The
only major
On Tuesday, 9 December 2014 at 22:24:51 UTC, Walter Bright wrote:
front() should return a 'scope ref string'.
That seems to contradict your other statement:
A 'scope ref' parameter may not be returned as a 'ref' or a
'scope ref'.
Just make it a 'ref' parameter.
Please check `foo()` once
On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
Because you don't really create a template that way but
workaround broken function behavior. It is not the usage of
empty templates that is bad but the fact that plain
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto
wrote:
The libraries contain the required metadata for symbol tables
and code locations that need to be extracted into the
executable/library.
Package definition files contain the minimum information the
compiler needs to know to
On Wednesday, 10 December 2014 at 21:39:42 UTC, Paulo Pinto wrote:
That was just an example, I could have written lots of other
stuff.
Then please show something that actually helps and is applicable
to D template system. There is not much value in vague references
with imagine rest yourself
On Thursday, 11 December 2014 at 03:30:07 UTC, Walter Bright
wrote:
If you want data to 'escape' from r.front, then it shouldn't be
marked as scope. Definitely, using scope successfully will
require some rethinking of how code is written.
Allowing or prohibiting escaping of r.front in that
On Thursday, 11 December 2014 at 08:30:55 UTC, Walter Bright
wrote:
On 12/10/2014 10:43 PM, Dicebot wrote:
On Thursday, 11 December 2014 at 03:30:07 UTC, Walter Bright
wrote:
If you want data to 'escape' from r.front, then it shouldn't
be marked as
scope. Definitely, using scope successfully
On Thursday, 11 December 2014 at 21:41:11 UTC, Walter Bright
wrote:
Consider a ref counted type, RC!T. If scope were transitive,
then you could not have, say, a tree where the edges were RC!T.
I.e., the payload of an RC type should not be forced to be
scope.
I don't see how this is related.
On Wednesday, 10 December 2014 at 21:57:42 UTC, deadalnix wrote:
struct S {
union {
T1 t1;
T2 t2;
}
T3 t3;
}
T1 a1;
T3 a3;
S(a1, a3);
This is erroring because t1 is set twice. It turns out that the
second parameter of the struct map to t2 rather than t3.
This
On Friday, 12 December 2014 at 00:13:10 UTC, deadalnix wrote:
Therefore, a `scope ref` return value can be passed on to the
next function as a `ref` argument. If that function again
returns a reference (even if not explicitly designated as
`scope`), the compiler will treat it as if it were
On Friday, 12 December 2014 at 07:48:21 UTC, Walter Bright wrote:
I don't see how this is related. It would be perfectly ok to
declare root of
such tree scope if it was transitive (as long as it only
controls access and
does not attempt early destruction).
Are you suggesting two kinds of
On Friday, 12 December 2014 at 06:57:54 UTC, deadalnix wrote:
On Friday, 12 December 2014 at 06:06:40 UTC, Dicebot wrote:
On Thursday, 11 December 2014 at 21:41:11 UTC, Walter Bright
wrote:
Consider a ref counted type, RC!T. If scope were transitive,
then you could not have, say, a tree where
On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via
Digitalmars-d wrote:
We were trying to use vibe.d, and we encountered bugs.
We were unable to build Win64 code ...
Here is exactly your problem - trying to do a web development on
Windows :P Really I have never understood that
On Saturday, 13 December 2014 at 00:10:07 UTC, Walter Bright
wrote:
The proposal provides escape proof passing of arguments. This
is necessary in order to make rc safe, for example.
What are you looking for?
I am looking for a tool to prevent escaping references to
user-defined entities /
On Monday, 15 December 2014 at 02:45:04 UTC, Walter Bright wrote:
1. All inout actually does is reduce code copy/pasta, it is not
critical.
Being forced to duplicate every single function in two flavors to
actually make scope system usable? This is as much critical as it
can be.
2. This
On Monday, 15 December 2014 at 07:48:37 UTC, Paulo Pinto wrote:
Well, lots of Fortune 500 companies do.
I have heard good enough first 9000 times, thanks.
If you want to appeal to those users
No.
Choosing the way of throwing away code is up to you. Contributing
in a way such it is acknowledged by upstream is defined by,
coincidentally, upstream. The line gets drawn exactly at the
moment where you are not satisfied with just throwing stuff away
but want to claim bounty / get review.
On Monday, 15 December 2014 at 06:12:05 UTC, Walter Bright wrote:
C++ seems to do fine without it for const. It's a convenience
feature.
C++ const does not really restrict or affect anything for real,
it is non-existent feature. `scope` as proposed would result in
inability to store result
On Monday, 15 December 2014 at 09:31:28 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 15 Dec 2014 09:07:53 +
uri via Digitalmars-d digitalmars-d@puremagic.com wrote:
You were looking forward to that, in fact I'd say trolling for
it...
that's not the first time i asking why bugzilla is still
On Monday, 15 December 2014 at 10:24:38 UTC, Artem Tarasov wrote:
On Monday, 15 December 2014 at 10:11:37 UTC, ketmar via
Digitalmars-d wrote:
nope. i'm accepting the fact that D is doomed to be a toy,
which
ocasionally used here and there. i tried to fight with this,
but this
fight is lost
On Monday, 15 December 2014 at 10:42:26 UTC, Paulo Pinto wrote:
On Monday, 15 December 2014 at 08:13:33 UTC, Dicebot wrote:
On Monday, 15 December 2014 at 07:48:37 UTC, Paulo Pinto
wrote:
Well, lots of Fortune 500 companies do.
I have heard good enough first 9000 times, thanks.
If you
On Monday, 15 December 2014 at 10:52:04 UTC, Artem Tarasov wrote:
Fair point. The trouble I have with D in particular is its
definition of 'quality'. For example, I'm unable to consider
THIS 'quality effort':
hhttps://github.com/tom-tan/phobos/commit/c7e99d9baff0749dfb334db322c5471b21a2539d
-
On Monday, 15 December 2014 at 11:25:43 UTC, Mengu wrote:
isn't that enterprise culture or communities/companies
interested in investing in programming languages made java, c#,
python and ruby mainstream?
Java / C# - huge amount of enterprise money invested into it from
the very start and
On Monday, 15 December 2014 at 11:23:28 UTC, Marc Schütz wrote:
I think there are two cases that are relevant. 1) the tree
nodes don't own their children, instead they are managed by -
let's say - a region allocator, and 2) the tree nodes do own
their children. In both cases, they can declare
On Monday, 15 December 2014 at 11:42:31 UTC, ponce wrote:
On Monday, 15 December 2014 at 10:46:30 UTC, Dicebot wrote:
I don't plan it and don't realistically ever expect it.
Considering the fact that game development industry is
traditionally one of the worst in contributing upstream I also
On Wednesday, 17 December 2014 at 08:30:59 UTC, Manu via
Digitalmars-d wrote:
Here is exactly your problem - trying to do a web development
on Windows :P
Really I have never understood that counter-productive
obsession with a
habit that makes people differentiate development environments
and
On Wednesday, 17 December 2014 at 10:33:34 UTC, ketmar via
Digitalmars-d wrote:
when i started to learn D, i found and read Andrei's book,
Ali's book
and Philippe's template tutorial. and i never complained that
phobos
reference documentation is hostile to beginners -- 'cause
it's NOT
for
On Wednesday, 17 December 2014 at 17:50:24 UTC, Nick Treleaven
wrote:
On 15/12/2014 19:39, H. S. Teoh via Digitalmars-d wrote:
If you put your git repo online somewhere, I wouldn't mind
pulling from
it and pushing to Phobos as PRs. It's much more convenient than
downloading patches off
On Thursday, 18 December 2014 at 10:24:46 UTC, Manu via
Digitalmars-d wrote:
People aren't allocated work time to read books.
Wait, really? X_X The more you tell about game dev culture and
your work experience there the more I feel sorry for people who
work there.
On Thursday, 18 December 2014 at 09:56:07 UTC, Manu via
Digitalmars-d wrote:
Of course it is language for nerds. Do you see a paid
developer team working
on D? At least ONE paid developer? Maybe someone of existing
commercial
users pays for adding tools / features? It is not a product,
it is
On Thursday, 18 December 2014 at 13:48:27 UTC, bioinfornatics
wrote:
please stop with this dub
It do not respect OS specification
Is a monolith application,inside they are at least 3 kinds of
software:
- a builder
- a package manager
- a package indexer
In any case the :
- no respect
How one can consider pip a good thing for packaging and blame dub
at the same time is beyond my comprehensions. I have nothing but
hatred against both pip and gems.
On Thursday, 18 December 2014 at 13:16:11 UTC, bioinfornatics
wrote:
about Dub, I have another view.
This build system was created for end user to get a missing
library when they want their killer application. As is done
with PyPI or gem.
Build system is never for end users but always for
Have you seen my http://wiki.dlang.org/DIP63 ?
On Thursday, 18 December 2014 at 16:15:09 UTC, Steven
Schveighoffer wrote:
On 12/18/14 10:44 AM, Dicebot wrote:
Have you seen my http://wiki.dlang.org/DIP63 ?
I admit this is somewhat over my head, but it seems to be more
focused on types.
In D there is no special built-in value tuple
I wasn't subscribed to druntime changes thus missed this
discussion. Will chime in there soon.
On Thursday, 18 December 2014 at 18:04:10 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Dec 18, 2014 at 03:44:18PM +, Dicebot via
Digitalmars-d wrote:
Have you seen my http://wiki.dlang.org/DIP63 ?
Ahhh, finally I understand what this DIP is all about. :-D
I like it. +1.
T
On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote:
me too. it's really disgusting how you guys treat (verbally
mistreat) others, who take a chance with D.
Good luck to you all on your pet project.
And how? Explaining mistakes and reasons why just taking a chance
brings nothing (and can
On Thursday, 18 December 2014 at 21:39:49 UTC, Vic wrote:
snip We have :
- a huge cemetery of D project
+ 1
What to do:
- Stop to add new feature in D (new annotation or whatever is
not an urgent needs)
+1000.
But this is not the culture of the creators. They think adding
features is
On actual plan of D development - I believe that if situation
stays the same existing companies and core contributors will need
to step up and take over management of the language at some
point, based on some well-defined decision making protocol. Right
language leadership is the bottleneck -
On Friday, 19 December 2014 at 13:33:08 UTC, Wyatt wrote:
On Friday, 19 December 2014 at 09:15:18 UTC, Walter Bright
wrote:
On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:
People aren't allocated work time to read books.
This can't be generally true. Most people who attend
programming
On Tuesday, 16 December 2014 at 01:00:47 UTC, Walter Bright wrote:
On 12/15/2014 5:38 AM, deadalnix wrote:
On Monday, 15 December 2014 at 11:32:11 UTC, Dicebot wrote:
For me scopeness is a property of view, not object itself
- this also
makes ownership method of actual data irrelevant. Only
On Saturday, 20 December 2014 at 07:26:30 UTC, Manu via
Digitalmars-d wrote:
Thank you.
I get so frustrated by the apparent majority in this forum who
seem to
think 'most' programmers are the type who would even read or
post on a
forum like this. Or read a programming book! They must surely
On Friday, 19 December 2014 at 10:47:28 UTC, Sergei Nosov wrote:
I think the most valuable point Manu made is that there are
excellent and good programmers. The difference is not so
much in the actual skills, but in the willing to spend time on
programming.
I would avoid calling those groups
On Friday, 19 December 2014 at 15:17:04 UTC, Steven Schveighoffer
wrote:
On 12/18/14 6:18 PM, Adam D. Ruppe wrote:
On Thursday, 18 December 2014 at 23:06:12 UTC, ketmar via
Digitalmars-d
wrote:
the only thing this will help is to hide bugs, i believe.
On the contrary, I find explicit casts
It can be added trivially added to Phobos, of course, if more
people consider it useful.
On Saturday, 20 December 2014 at 12:19:34 UTC, Bienlein wrote:
I would say that D needs a usecase that puts it aside from
other languages. For Java this was the Internet. For Go it was
channel-based concurrency in conjunction with some style of
green threads (aka CSP). It is now the time of
People have already suggested you to actually try vibe.d at least
once before repeating CSP is necessary for easy async mantra.
How about actually doing so? vibe.d + std.concurrency gives you
pretty much standard actor model - it lacks more complicated
schedulers and network message passing
On Saturday, 20 December 2014 at 15:14:28 UTC, Bienlein wrote:
On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto
wrote:
That is why I seldom buy into hype driven development.
Okay, so Docker is hype? Have you seen the impact of it? Every
Java magazine has articles about Docker.
On Saturday, 20 December 2014 at 19:11:53 UTC, Vic wrote:
Second smaller thing I 'elude' to but don't verbalize in that
argument is my personal preference for a smaller language. Less
is better/faster.
I think this is the main reason why we have different perspective
on necessity of change.
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
Nice but not important, unless you mean full tuple redesign (not
realistic)
- working
On Saturday, 20 December 2014 at 21:47:24 UTC, Walter Bright
wrote:
I did notice this:
I updated the ldc D compiler earlier today (incidentally, as
part of upgrading my system with pacman -Syu), and now it
doesn't compile at all. It was previously compiling, and ran at
around 90% the speed
On Sunday, 21 December 2014 at 09:58:42 UTC, bearophile wrote:
Dicebot:
- tuple support (DIP32, maybe without pattern matching)
Nice but not important, unless you mean full tuple redesign
(not realistic)
Full tuples (without pattern matching) are quite realistic in
D. Tuples have a
On Saturday, 20 December 2014 at 21:39:44 UTC, Walter Bright
wrote:
On 12/19/2014 9:44 PM, Dicebot wrote:
Such notion of view requires at least some elements of
transitivity to be
practical in my opinion.
I have no idea how some elements of transitivity can even
work. It's either transitive
On Sunday, 21 December 2014 at 08:23:34 UTC, deadalnix wrote:
See also: https://issues.dlang.org/show_bug.cgi?id=10996
I have nothing against this, but this is, indeed, completely
out of the scope (!) of the DIP.
I think it belongs to DIP22
On Sunday, 21 December 2014 at 10:33:09 UTC, Russel Winder via
Digitalmars-d wrote:
On Sun, 2014-12-21 at 09:30 +, Dicebot via Digitalmars-d
wrote:
[…]
This is very definition of hype. Yes, Go is hugely overblown
and it has nothing to do with any of its technical features.
Only
On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg wrote:
On 2014-12-21 10:46, Dicebot wrote:
- better user-defined type support (any built-in type must be
possible
to emulate via user aggregate)
Any specifics to achieve this?
Stuff that immediately comes to my mind:
- some way
On Monday, 22 December 2014 at 03:07:53 UTC, Walter Bright wrote:
On 12/21/2014 2:06 AM, Dicebot wrote:
No, it is exactly the other way around. The very point of what
I am saying is
that you DOESN'T CARE about ownership as long as worst case
scenario is
assumed. I have zero idea why you
On Monday, 22 December 2014 at 11:45:55 UTC, logicchains wrote:
I installed the new Arch Linux LDC package but it still fails
with the same error: /usr/lib/libldruntime.so: undefined
reference to `__mulodi4'
I did get GDC to work on ARM, but for some reason the resulting
executable is
On Tuesday, 23 December 2014 at 07:21:20 UTC, Iain Buclaw via
Digitalmars-d wrote:
Maybe you could set up a qemu-arm chroot?
Probably I should. Didn't bother originally because ARM support
is not part of Arch Linux upstream - it is separate project with
own packaging infrastructure, they
On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu
wrote:
Congratulations, Igor! -- Andrei
Good to see that.
It is a big feature though with a notable impact on symbol
resolution. How about providing it as a separate compiler build
for a release or two before deploying as
On Wednesday, 24 December 2014 at 06:18:56 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 24 December 2014 at 06:13:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Tue, Dec 23, 2014 at 11:05:05PM +, Vic via
Digitalmars-d wrote:
http://wiki.dlang.org/DIP66
One more feature.
[...]
Which
On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:
On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:
On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei
Alexandrescu wrote:
resolution. How about providing it as a separate compiler build
I feel like dropping D1 was
On Wednesday, 24 December 2014 at 14:04:56 UTC, ketmar via
Digitalmars-d wrote:
Hello.
i was never thinking about it, but recently i found parts of
source
code in my compiled D binary. they comes from code generation
functions, which only used in compile time, yet still happily
sits in
On Wednesday, 24 December 2014 at 14:15:40 UTC, ketmar via
Digitalmars-d wrote:
yet we have two other compilers too. i didn't checked what GDC
does
with --gc-sections cli switch, but i think that it doesn't
matter.
GDC is not there yet but I remember someone working on it. It
needs tweaks to
On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei
Alexandrescu wrote:
An emerging pattern (which Walter will effect for dip69) is to
initially make it opt-in as a flag:
dip -dip69 test.d
Great!
Though I would suggest -dip=69 as a small tweak for a bit more
robust CLI (leaves
On Wednesday, 24 December 2014 at 22:13:26 UTC, Andrei
Alexandrescu wrote:
On 12/24/14 5:54 AM, Dicebot wrote:
Only reason why D1 is still used here is huge effort
investment to
actually port that much code without ever delaying normal
deployment
schedule - and I am working on this to change
On Wednesday, 24 December 2014 at 14:27:38 UTC, eles wrote:
On Wednesday, 24 December 2014 at 13:54:24 UTC, Dicebot wrote:
On Wednesday, 24 December 2014 at 13:16:32 UTC, eles wrote:
On Wednesday, 24 December 2014 at 12:59:33 UTC, Dicebot wrote:
On Tuesday, 23 December 2014 at 15:49:46 UTC,
On Saturday, 27 December 2014 at 14:59:58 UTC, newbe wrote:
does that mean, that sociomantics is writing crappy, fault prone
and unusable software?
they are the praised light on D's sky when evangelizing D, even
if everybody thinks they are using D2.
are they dumb or just uneducated?
That
You can't speak about resurrecting language without considering
costs of resurrecting the toolchain - unless one wants to write
programs exclusively with pen and paper of course.
But I do recognize the troll pattern now, thanks.
On Wednesday, 24 December 2014 at 03:11:40 UTC, Andrei
Alexandrescu wrote:
On 12/20/14 6:47 PM, Steven Schveighoffer wrote:
On 12/20/14 5:20 AM, Dicebot wrote:
I'd like to have a cast where you must define both from and
to types
precisely.
I was actually thinking the same thing. This would
On Thursday, 25 December 2014 at 10:06:35 UTC, Martin Nowak wrote:
On Sunday, 21 December 2014 at 12:48:42 UTC, Dicebot wrote:
On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg
wrote:
On 2014-12-21 10:46, Dicebot wrote:
Stuff that immediately comes to my mind:
- some way to define
On Friday, 26 December 2014 at 01:11:42 UTC, Manu via
Digitalmars-d wrote:
Many bug reports and case studies, and often, a persistent
voice for
minority issues that don't get enough attention. My time spent
arguing
in this forum is substantial, and as annoying as it may seem, I
think
if I
On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby
wrote:
This is probably the most disgusting, selfish and deluded posts
i've read on this entire newsgroup.
I am pretty sure I have written worse.
If D is supposed to supplant C/C++, then the needs of those
users *must* be met,
On Monday, 22 December 2014 at 20:51:46 UTC, Walter Bright wrote:
On 12/22/2014 12:04 AM, Dicebot wrote:
Point of transitive scope is to make easy to expose complex
custom data
structures without breaking memory safety.
I do understand that. Making it work with the type system is
another
On Monday, 29 December 2014 at 15:50:15 UTC, Andrei Alexandrescu
wrote:
I see. I guess it's easy to add std.conv.explicitCast and
std.conv.implicitCast if there's enough impetus for it. --
Andrei
Yes, exactly. That was why I have asked general opinion about it
- don't want to add yet another
On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:
If anybody cared about good Windows debugging support or
getting vibe.d working flawlessly on Windows, they'd have done
it already. Now, Manu might bring more attention to those
issues through his post and someone may decide to work
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu
wrote:
Walter's reasoning was: we have inout for propagating
qualifiers from a parameter (this is also a parameter) to the
output, so we can use it for propagating aliasing information
as well.
Yay! I have been asking for it
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu
wrote:
I tend to agree. You seem to have shown that reusing inout for
scope information becomes confusing. -- Andrei
What is the problem with using inout exactly as it is now (==
both for argument and return type) but defining
On Monday, 29 December 2014 at 19:54:33 UTC, Steven Schveighoffer
wrote:
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei
Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout
for scope
information becomes confusing. -- Andrei
I'd better respond when I will not be as angry and tempted to go
into accusation mode.
On Monday, 29 December 2014 at 19:40:41 UTC, Mathias LANG wrote:
I'm wondering where we currently are on the process of releasing
2.067 ?
The reference page
http://wiki.dlang.org/Beta_Testing#Available_Downloads , is
horribly outdated, as DMD v2.066.1 was released, all known
regressions are
On Monday, 29 December 2014 at 20:20:45 UTC, Steven Schveighoffer
wrote:
But this precludes doing anything with a mutable t inside foo,
since inout means const within the function.
Hm, yes, this is indeed quite the problem. I have totally forgot
that compiler has no means of figuring out
On Monday, 29 December 2014 at 21:29:21 UTC, Steven Schveighoffer
wrote:
I think it wouldn't be a bad idea to investigate a new way to
express attributes, but I think no matter what we do, we need
to rein in the explosion of attributes that needs to be put on
every function.
For that I think
DDOC is probably one of D features with pretty idea and hardly
usable design. I wish we had something like Markdown instead -
can never remember Phobos macros to use and usually just resort
to using plain text instead.
On Monday, 29 December 2014 at 22:35:50 UTC, Walter Bright wrote:
On 12/29/2014 12:02 PM, Jacob Carlborg wrote:
On 2014-12-29 20:47, Walter Bright wrote:
It uses something pretty similar. They all kinda mush
together in my
mind :-(
Don't blame Markdown just because some other markup
On Tuesday, 30 December 2014 at 15:48:03 UTC, Steven
Schveighoffer wrote:
On 12/18/14 11:54 AM, Dicebot wrote:
I wasn't subscribed to druntime changes thus missed this
discussion.
Will chime in there soon.
Ping, still waiting on this :)
-Steve
*blush*
On Tuesday, 30 December 2014 at 16:25:05 UTC, Steven
Schveighoffer wrote:
On 12/30/14 10:51 AM, Dicebot wrote:
On Tuesday, 30 December 2014 at 15:48:03 UTC, Steven
Schveighoffer wrote:
On 12/18/14 11:54 AM, Dicebot wrote:
I wasn't subscribed to druntime changes thus missed this
discussion.
On Tuesday, 30 December 2014 at 00:25:28 UTC, Walter Bright wrote:
Criticism about documentation is actually very well-placed -
it is an issue that
affects everyone, can be fixed in small chunks and does not
require huge effort
investment for each chunk. No one loses, everyone wins, yay!
I
On Wednesday, 31 December 2014 at 03:25:24 UTC, Manu via
Digitalmars-d wrote:
His point is similar to my other point elsewhere though. I
don't think
he's talking about 'power' in the sense you describe, what he's
really
talking about is consistency or uniformity. His original scope
proposal
So, getting back to this. What do I see wrong in this thread? It
creates a clear message : you don't really want to be a D
contributor.
Once you start doing it, all privileges of doubt that belong to
user are lost and bunch of obligations suddenly appears. And of
all obligation worst
On Wednesday, 31 December 2014 at 19:50:49 UTC, Andrei
Alexandrescu wrote:
Hello,
In wake of the recent discussions on improving ddoc syntax
we're looking at doing something about it. Please discuss any
ideas you might have here. Thanks!
One simple starter would be to allow one escape
On Wednesday, 31 December 2014 at 21:37:37 UTC, H. S. Teoh via
Digitalmars-d wrote:
Very nice! Now make it work for int* and string*, but indexing
the tuple
returns (non-pointer) int and string. This is the original use
case that
prompted this ER, btw, so if it can't be achieved, then we
On Wednesday, 31 December 2014 at 22:05:37 UTC, H. S. Teoh via
Digitalmars-d wrote:
Point. But that means we've gone nowhere with AA .byPair().
If I wanted to stir up controversy, I'd say that the ultimate
cause of
this issue was the fact that struct fields can't be ref;
otherwise it
would be
On Wednesday, 31 December 2014 at 22:41:41 UTC, Ary Borenszweig
wrote:
You are right. I browsed some phobo's code and saw the
documentation, it looks clean and nice. The only exception is
std.algorithm which is full of macros and barely readable.
So where is that other macro code? The one
On Wednesday, 31 December 2014 at 22:47:05 UTC, H. S. Teoh via
Digitalmars-d wrote:
That's what I have right now. The catch is how to make S behave
like a
tuple.
I don't know why it was considered an important/worthy goal.
Trying to provide API based on tuples just hides the fact that
there
On Wednesday, 31 December 2014 at 22:53:14 UTC, Ary Borenszweig
wrote:
It looks quite clean to me:
https://github.com/D-Programming-Language/dlang.org/blob/master/arrays.dd
One of the very first lines:
$(TABLE2 Kinds of Arrays,
$(THEAD Syntax, Description)
$(TROW $(ARGS
On Wednesday, 31 December 2014 at 22:58:57 UTC, H. S. Teoh via
Digitalmars-d wrote:
people demanded Tuple support.
Was it bearophile? :P I can't stop feeling that it is simply not
recognized enough how bad D tuples are if such request arises.
I'd personally try to avoid those in almost all
On Thursday, 1 January 2015 at 00:21:42 UTC, Walter Bright wrote:
It's quite unfair to not bother with whitespace formatting in
one but not the other. It's like the before and after
advertisements for cosmetics where the before has uncombed
hair, poor lighting, is frowning, didn't brush their
Something that creates an API bridge between different external
libraries is naturally a good fit for Phobos and exactly type of
additions I'd like to see there. I think only concern is where
exactly to put it : std.media.image.colour sounds like a most
fitting qualified path to me but that is
801 - 900 of 2167 matches
Mail list logo
