I agree - the current state with both null and non-null empty
arrays is confusing, and the separate syntax for empty arrays and
associative arrays is nice and consistent.
I would go as far as to say it should be impossible, or at least
fairly difficult in safe code to distinguish (both intenti
On Sunday, 30 June 2013 at 10:21:12 UTC, TommiT wrote:
Perhaps an interesting observation about this is that while in
C++ const correctness literally never improves performance [1],
in D (if these optimizations were implemented) const
correctness could potentially increase performance considera
On Sunday, 30 June 2013 at 09:46:00 UTC, Maxim Fomin wrote:
In the 9498 issue there is a discussion about such code:
string[string] myValues;
ref string getValue(string v) {
return myValues[v];
}
void main() {
getValue("myValue") = "myString";
}
Currently it throws range violation as my
If this is indeed Diggory's point, it's not very pointy
(sorry). The compiler should be able to safely omit the
postblit on 's' when it passes it to foo (and the possible
destructor of foo's argument inside foo when foo exits).
If the postblit is omitted, and the function or code it calls
acc
On Saturday, 29 June 2013 at 17:57:33 UTC, TommiT wrote:
On Saturday, 29 June 2013 at 13:47:36 UTC, TommiT wrote:
[..]
Example:
struct S
{
int[] values;
this(this)
{
values = values.dup;
}
}
void foo(const S) { }
void main()
{
const S s;
foo(s); // No need to c
On Friday, 21 June 2013 at 22:56:04 UTC, Andrei Alexandrescu
wrote:
On 6/21/13 3:55 PM, Andrei Alexandrescu wrote:
On 6/21/13 3:45 PM, Timothee Cour wrote:
I'd like to support N-ary map, ie std.algorithm.map that
takes 1 or more
ranges as arguments and operates lazily on those.
Actually map
On Sunday, 9 June 2013 at 12:19:13 UTC, Peter Alexander wrote:
On Sunday, 9 June 2013 at 10:49:17 UTC, Jonathan M Davis wrote:
On Sunday, June 09, 2013 12:33:39 Peter Alexander wrote:
It looks like the core issue here is that it's simply not
possible to create a mutable copy of a const object w
On Wednesday, 5 June 2013 at 17:36:05 UTC, Andrei Alexandrescu
wrote:
On 6/5/13 1:10 PM, Jonathan M Davis wrote:
On Wednesday, June 05, 2013 07:49:22 H. S. Teoh wrote:
(Actually, std.algorithm currently sits at 11636 lines. I
call BS on
whoever claims to be able to "skim over" std.algorithm and
On Wednesday, 5 June 2013 at 17:21:01 UTC, Jonathan M Davis wrote:
On Wednesday, June 05, 2013 14:02:37 Jakob Ovrum wrote:
We have a standard library in disagreement with the language's
encapsulation mechanics. The module/package system in D is
almost
ignored in Phobos (and that's probably why
On Wednesday, 5 June 2013 at 11:30:10 UTC, John Colvin wrote:
On Wednesday, 5 June 2013 at 08:11:14 UTC, Walter Bright wrote:
On 6/5/2013 12:38 AM, Jonathan M Davis wrote:
Maybe some do, but many don't, and 1000 lines is _far_ from
too much. If we
start making modules that small, we're going to
On Tuesday, 4 June 2013 at 03:44:05 UTC, Walter Bright wrote:
https://github.com/WalterBright/phobos/blob/std_compress/std/compress.d
I wrote this to add components to compress and expand ranges.
Highlights:
1. doesn't do any memory allocation
2. can handle arbitrarily large sets of data
3. it
On Monday, 3 June 2013 at 17:36:13 UTC, Maxim Fomin wrote:
On Monday, 3 June 2013 at 16:46:15 UTC, Diggory wrote:
On Monday, 3 June 2013 at 12:13:30 UTC, Maxim Fomin wrote:
On Monday, 3 June 2013 at 11:12:10 UTC, Diggory wrote:
On Monday, 3 June 2013 at 05:56:42 UTC, Maxim Fomin wrote:
On
On Monday, 3 June 2013 at 12:13:30 UTC, Maxim Fomin wrote:
On Monday, 3 June 2013 at 11:12:10 UTC, Diggory wrote:
On Monday, 3 June 2013 at 05:56:42 UTC, Maxim Fomin wrote:
On Monday, 3 June 2013 at 02:23:18 UTC, Andrej Mitrovic wrote:
Let's say you define an enum, which is to be used
On Monday, 3 June 2013 at 05:56:42 UTC, Maxim Fomin wrote:
On Monday, 3 June 2013 at 02:23:18 UTC, Andrej Mitrovic wrote:
Let's say you define an enum, which is to be used as a
variable:
...
Thoughts?
I think it is simpler to set a first enum member as invalid.
However, I like an idea of su
On Monday, 3 June 2013 at 02:23:18 UTC, Andrej Mitrovic wrote:
Let's say you define an enum, which is to be used as a variable:
enum Machine
{
X86,
X86_64,
}
So off you go and let the users (or yourself) use this in code:
-
void main()
{
Machine machine;
...
callSomethi
On Sunday, 2 June 2013 at 18:43:44 UTC, monarch_dodra wrote:
On Sunday, 2 June 2013 at 16:55:23 UTC, Andrei Alexandrescu
wrote:
On 6/2/13 11:41 AM, monarch_dodra wrote:
On Sunday, 2 June 2013 at 13:07:18 UTC, Andrei Alexandrescu
wrote:
[1, 2, 3, 4].map!(n => n.writeln).reduce;
Andrei
One o
On Saturday, 1 June 2013 at 11:50:23 UTC, bearophile wrote:
As example the very small but fast virtual machine written in
GNU C++ from the International Contest on Functional
Programming 2006:
http://codepad.org/iibBeWKw
It's faster than the same code without computed gotos.
Bye,
bearophile
So, I've been thinking about a few of the current problems with D:
- No allocators on containers
- Standard library functions doing too much GC allocation
- Escaping pointers to memory not allocated using the GC
- Implicit allocation with "~", "~=" and array literals
And I came up with something
On Thursday, 30 May 2013 at 21:40:47 UTC, js.mdnq wrote:
On Thursday, 30 May 2013 at 12:32:46 UTC, bearophile wrote:
If you don't like to introduce a new keyword, then a different
alternative is to use the @ again, a bit like UDAs:
@{...}
@[10] @{int, string} tup = @{1, "hi"}; // With UDA.
fo
On Thursday, 30 May 2013 at 16:59:42 UTC, Timothee Cour wrote:
In this:
auto:
x = 1;
y = 2;
f = a => a+1
writeln(f(x) + y);
where do you delimit the end of the 'auto:' scope?
At the end of the current scope - same rules as normal.
You can use { ... } to create a new scope where ne
On Thursday, 30 May 2013 at 14:26:11 UTC, watcher wrote:
On Thursday, 30 May 2013 at 14:06:15 UTC, Diggory wrote:
Could also do something in the style of token strings, ie.
t{ ... }
It's lighter than "tup" and there's a precedent for it already
in the language with q{ ..
On Thursday, 30 May 2013 at 15:05:40 UTC, monarch_dodra wrote:
On Thursday, 30 May 2013 at 14:55:38 UTC, someone wrote:
Please think about the huge math and science community. Most
of them I came across like D for its speed and efficiency. But
D can never replace Matlab/Octave/Ipython/Scipy bec
Could also do something in the style of token strings, ie.
t{ ... }
It's lighter than "tup" and there's a precedent for it already in
the language with q{ ... } which also means there should be no
issues parsing it.
On Thursday, 30 May 2013 at 11:34:20 UTC, Dicebot wrote:
On Thursday, 30 May 2013 at 11:31:53 UTC, Manu wrote:
Which 'both' cases?
"OS support for fork+CoW" vs "no support, own implementation"
If you can modify the DMD compiler to output a special sequence
of instructions whenever you assig
On Thursday, 30 May 2013 at 07:15:39 UTC, Jonathan M Davis wrote:
On Thursday, May 30, 2013 09:01:06 Maxim Fomin wrote:
> The article about slices on this site -
> http://dlang.org/d-array-article.html is perfectly correct.
No, the article is incorrect in vocabulary because it
contradicts
to
On Thursday, 30 May 2013 at 05:54:57 UTC, Maxim Fomin wrote:
On Thursday, 30 May 2013 at 05:44:43 UTC, Diggory wrote:
On Thursday, 30 May 2013 at 05:41:06 UTC, Maxim Fomin wrote:
On Wednesday, 29 May 2013 at 23:45:04 UTC, Ali Çehreli wrote:
On 05/29/2013 03:59 PM, Peter Williams wrote
On Thursday, 30 May 2013 at 05:41:06 UTC, Maxim Fomin wrote:
On Wednesday, 29 May 2013 at 23:45:04 UTC, Ali Çehreli wrote:
On 05/29/2013 03:59 PM, Peter Williams wrote:
> I've been trying to find out how non ref array arguments are
passed to
> functions in D but can't find any documentation on
On Thursday, 30 May 2013 at 02:51:47 UTC, Diggory wrote:
On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:
Diggory: That's very cool -- being able to do that in D.
Thanks for showing me :)
But it is not even a remotely practical solution.
The idea is to write less, and s
On Thursday, 30 May 2013 at 01:35:58 UTC, MrzlganeE wrote:
Diggory: That's very cool -- being able to do that in D.
Thanks for showing me :)
But it is not even a remotely practical solution.
The idea is to write less, and so the solution you've given
is to write more mixins al
On Thursday, 30 May 2013 at 00:20:00 UTC, MrzlganeE wrote:
Hi,
Please consider a request for just one piece of syntax sugar in
D.
In places where I write a bunch of short mathy code, I do not
want to use 'auto'. The := operator would allow to declare a
variable, deduce its type, and define
On Wednesday, 29 May 2013 at 16:24:00 UTC, Timon Gehr wrote:
On 05/29/2013 06:21 PM, Timon Gehr wrote:
On 05/29/2013 07:35 AM, Walter Bright wrote:
On 5/28/2013 9:55 PM, Diggory wrote:
As a last resort there should be a runtime check available
such as
assertNotNull(T) which does the
On Wednesday, 29 May 2013 at 10:33:32 UTC, deadalnix wrote:
On Wednesday, 29 May 2013 at 07:32:42 UTC, Jeremy DeHaan wrote:
Thoughts?
static variables are thread local. Are you sure the destructor
run in the same thread as the constructor ?
Either way "remove" should simply fail not give a
On Wednesday, 29 May 2013 at 05:35:14 UTC, Walter Bright wrote:
On 5/28/2013 9:55 PM, Diggory wrote:
As a last resort there should be a runtime check available
such as
assertNotNull(T) which does the conversion.
The idea is to put the check on assignments to NotNull, not on
usage of it.
I
On Wednesday, 29 May 2013 at 04:48:07 UTC, Russel Winder wrote:
On Tue, 2013-05-28 at 13:46 -0400, Jonathan M Davis wrote:
[…]
Do you mean something like std.mmfile.MmFile which operates on
a file as an array in memory using mmap, or do you mean
operating on memory that has no connection to a f
On Wednesday, 29 May 2013 at 04:15:52 UTC, Walter Bright wrote:
On 5/28/2013 7:40 PM, Jesse Phillips wrote:
On Monday, 27 May 2013 at 07:53:05 UTC, Walter Bright wrote:
In D, right now (and especially with the beta) you can use
the NotNull template.
Where is this NotNull template? If it was i
On Wednesday, 29 May 2013 at 01:33:57 UTC, Steven Schveighoffer
wrote:
On Tue, 28 May 2013 21:19:49 -0400, Ali Çehreli
wrote:
// C is a class
const(C) c = new const(C);
// c promises that it won't mutate the object.
// Why can't it promise to not mutate another object?
c
Yes, that's Kenji's initial suggestion, which I can use for
Ah, didn't see it because the forum keeps breaking threads up
into little pieces...
On Tuesday, 28 May 2013 at 23:33:47 UTC, Peter Williams wrote:
On 28/05/13 19:12, Jacob Carlborg wrote:
On 2013-05-28 08:00, Manu wrote:
Is there anywhere other than America that doesn't?
Canada, Jamaica, other countries in that region?
Last time I looked Canada was in America (which is a
On Tuesday, 28 May 2013 at 17:24:13 UTC, H. S. Teoh wrote:
On Tue, May 28, 2013 at 11:37:06AM +0200, bearophile wrote:
Timothee Cour:
>python uses itertools.product which is lexicographic_depth.
>Like you
>say, no-one can agrees what the order should be, so let's
>leave it up
>to user throug
On Tuesday, 28 May 2013 at 13:41:42 UTC, Manu wrote:
So I've run into an expression I need to be able to implement
std.simd
properly for GDC/LDC.
Doesn't work:
@attribute("target", T) void func(string T)(...);
In this case, currently, the UDA can't receive the template arg
that was
given t
On Tuesday, 28 May 2013 at 04:52:55 UTC, Walter Bright wrote:
On 5/27/2013 9:27 PM, Manu wrote:
I will never write colour without a u, ever! I may suffer the
global American
cultural invasion of my country like the rest of us, but I
will never let them
infiltrate my mind! ;)
Resistance is us
On Tuesday, 28 May 2013 at 02:32:24 UTC, Lionello Lunesu wrote:
Walter,
Any chance we can get the source of htod? If found it a very
useful little utility, although there are many issues with it.
VisualD also include a similar utility to convert header files
to D, but it is more tuned to Win
Using StaticTuple clearly and unambiguously refers to the alias
to a "..." template argument.
Right now, that's TypeTuple. The fact that Type is in the name
means nothing
other than the fact that it was poorly named. I'm quite certain
that a number
of the template-heavy projects out there use
On Tuesday, 28 May 2013 at 00:11:18 UTC, Walter Bright wrote:
On 5/27/2013 4:28 PM, Hans W. Uhlig wrote:
On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
I've recently come to the opinion that that's a bad idea, and
D should not
support it.
Why do you think its a bad idea? It mak
On Monday, 27 May 2013 at 20:34:30 UTC, Peter Alexander wrote:
On Monday, 27 May 2013 at 20:14:35 UTC, Andrei Alexandrescu
wrote:
At some point Walter and I were talking about generating an MD
hash for very long names. That has some disadvantages (i.e. no
easy reverse lookup) but it may work.
On Monday, 27 May 2013 at 13:42:51 UTC, Timon Gehr wrote:
It is not that similar, as it automatically expands into any
context and hence does not allow a nested structure.
The point being? It's true that there is some special behaviour,
but that's the same regardless of whether it's called St
I gather this has been discussed before and even a potential
solution submitted
(https://github.com/D-Programming-Language/phobos/pull/780)
However it was dismissed due to too much existing code being
broken.
I'd like to suggest a slightly less severe change which should
still fix the issue
On Monday, 27 May 2013 at 03:28:07 UTC, deadalnix wrote:
On Monday, 27 May 2013 at 02:31:50 UTC, Jonathan M Davis wrote:
On Monday, May 27, 2013 04:24:51 Diggory wrote:
It also shouldn't break any code since the only addition to
TypeTuple is a check to make sure that the undocum
On Monday, 27 May 2013 at 02:31:50 UTC, Jonathan M Davis wrote:
On Monday, May 27, 2013 04:24:51 Diggory wrote:
It also shouldn't break any code since the only addition to
TypeTuple is a check to make sure that the undocumented
behaviour
of using it with non-types is disallowed, and i
On Monday, 27 May 2013 at 01:36:58 UTC, Jonathan M Davis wrote:
On Monday, May 27, 2013 11:21:08 Manu wrote:
I have certainly been confused by the term 'tuple' used in D
countless
times.
It seems to exist in a variety of different contexts, and
every time I
think I understood it, I realise I'm
Bugs occur when two parts of the program make slightly different
assumptions about the interface between them.
Semantically checking those assumptions will always help, but it
will also always be limited. The idea that code will always
branch on nullable types and handle both cases is wishful
On Sunday, 26 May 2013 at 15:48:00 UTC, Russel Winder wrote:
I wonder if people coming to D, looking for information about
tuples,
will get confused by http://dlang.org/tuple.html which seems to
tell
people they have to "roll their own", and
http://dlang.org/phobos/std_typecons.html which tells
On Saturday, 25 May 2013 at 20:03:59 UTC, Joakim wrote:
I have noted from the beginning that these large alphabets have
to be encoded to two bytes, so it is not a true constant-width
encoding if you are mixing one of those languages into a
single-byte encoded string. But this "variable length"
On Saturday, 25 May 2013 at 19:02:43 UTC, Joakim wrote:
On Saturday, 25 May 2013 at 18:09:26 UTC, Diggory wrote:
On Saturday, 25 May 2013 at 08:07:42 UTC, Joakim wrote:
On Saturday, 25 May 2013 at 07:48:05 UTC, Diggory wrote:
I think you are a little confused about what unicode
actually is
"limited success of UTF-8"
Becoming the de-facto standard encoding EVERYWERE except for
windows which uses UTF-16 is hardly a failure...
I really don't understand your hatred for UTF-8 - it's simple to
decode and encode, fast and space-efficient. Fixed width
encodings are not inherently fast
On Saturday, 25 May 2013 at 08:07:42 UTC, Joakim wrote:
On Saturday, 25 May 2013 at 07:48:05 UTC, Diggory wrote:
I think you are a little confused about what unicode actually
is... Unicode has nothing to do with code pages and nobody
uses code pages any more except for compatibility with
I think you are a little confused about what unicode actually
is... Unicode has nothing to do with code pages and nobody uses
code pages any more except for compatibility with legacy
applications (with good reason!).
Unicode is:
1) A standardised numbering of a large number of characters
2) A
On Saturday, 25 May 2013 at 02:41:00 UTC, Brad Anderson wrote:
On Friday, 24 May 2013 at 19:44:23 UTC, Jonathan M Davis wrote:
We already have stuff like format vs formattedWrite where one
allocates and the
other takes an output range. We should adopt that practice in
general. Where
possible, i
On Thursday, 23 May 2013 at 08:31:46 UTC, Jacob Carlborg wrote:
On 2013-05-23 10:29, Jacob Carlborg wrote:
Say I have:
gettext("%s: unknown variable at line %s")
Then I want to change the text to:
gettext("%s: not yet known variable at line %s")
I have to find all places where this text is
On Thursday, 23 May 2013 at 07:19:46 UTC, Jacob Carlborg wrote:
On 2013-05-23 08:27, Peter Williams wrote:
An example of how I would envisage gettext being used in D is:
writefln(gettext("%s: unknown variable at line %s"), filename,
linenumber);
It is a common practice, to define a macro (o
I've been looking at GtkD and it seems very complete and up to
date in terms of exposing the Gtk+ API and wrapping it, but
there's still a lot of Dification that could be done which would
make it much closer to an ideal gui toolkit:
- Compile time implementation of GtkBuilder
- Instead of conn
On Tuesday, 21 May 2013 at 18:59:08 UTC, Jacob Carlborg wrote:
I would expect that the system needs to be designed from the
ground up with support for something like internationalization.
There are probably other features were this is true as well.
Of course, although I think internationalizat
On Tuesday, 21 May 2013 at 12:12:12 UTC, Jacob Carlborg wrote:
On 2013-05-20 22:40, Diggory wrote:
UI toolkits are a lot of work but they're not as unreasonably
big as
everyone seems to be suggesting... I've written a couple
myself in a
procedural language using Direct3D to draw
See my DConf talk in a few days (I was #3 on Day 2). It has a
pattern for concurrent data mutation at the end that might be
more useful than a global lock, which has some pretty
disturbing implications for high-performance rendering code.
I can't help but feel that making them concurrent is
On Tuesday, 21 May 2013 at 02:47:59 UTC, Adam Wilson wrote:
could care less
http://www.youtube.com/watch?v=om7O0MFkmpw
Sorry...
On Monday, 20 May 2013 at 23:40:34 UTC, Andrej Mitrovic wrote:
On 5/21/13, Adam Wilson wrote:
Sub-pixel font hinting. Almost no games use this, and almost
every OS
toolkit does.
There used to be a nice article about font rendering in OpenGL
(methinks) here: http://h3.gd/dmedia/?n=Tutorials.T
On Monday, 20 May 2013 at 22:02:57 UTC, Idan Arye wrote:
On Monday, 20 May 2013 at 19:15:34 UTC, Dmitry Olshansky wrote:
20-May-2013 22:14, Idan Arye пишет:
1) It doesn't matter if the object is not ready, because when
you want
to actually access the object, you need to use `instance()`
which
UI toolkits are a lot of work but they're not as unreasonably big
as everyone seems to be suggesting... I've written a couple
myself in a procedural language using Direct3D to draw
everything. Had all the standard controls, various layout
options, even a syntax highlighted code editor, clipboar
On Monday, 20 May 2013 at 06:53:34 UTC, Idan Arye wrote:
On Monday, 20 May 2013 at 05:39:42 UTC, Diggory wrote:
In your logic you're assuming that the order of operations is
maintained - without the correct memory barriers or
synchronisation both the compiler and CPU are free to
compl
In your logic you're assuming that the order of operations is
maintained - without the correct memory barriers or
synchronisation both the compiler and CPU are free to completely
reorder any operations you do. That's why it's always a bug to
access mutable shared data without synchronisation -
There is no point in saving a thread local reference to the
global instance. The `__gshared` instance is never changed once
initialized, so if we saved a thread local reference, it would
*always* be either null or the same as the `__gshared` one -
which means that if the local reference is no
On Saturday, 18 May 2013 at 16:58:19 UTC, Idan Arye wrote:
OK, I implemented everything and made a pull request:
https://github.com/D-Programming-Language/phobos/pull/1294
Nice, but the singleton implementation seems somewhat
over-complicated, and the low-lock singleton is broken, possibly
as
I think we all understand it's not going to catch every race
condition, or even a given race condition every time, ie. it
can't prove that the code is correct.
What it can do however is prove that code is incorrect. If the
unit test fails there is definitely something wrong with the
code, the
On Wednesday, 15 May 2013 at 18:28:53 UTC, Idan Arye wrote:
I'm making an idioms
library(http://forum.dlang.org/thread/fofbrlqruxbevnxch...@forum.dlang.org)
to add to Phobos, and one of the idioms is the singleton design
pattern. Since I'm gonna send it to Phobos, it needs to have a
unit test.
On Sunday, 12 May 2013 at 18:42:22 UTC, deadalnix wrote:
On Sunday, 12 May 2013 at 18:09:59 UTC, Walter Bright wrote:
I think that is irrelevant to my point. A language doesn't
have to be text based.
Textual format have proven theur usefullness again and again.
Programming languages, json, xm
On Sunday, 12 May 2013 at 01:16:43 UTC, Simen Kjaeraas wrote:
I believe you're overthinking this. First, what is global
unique variable?
A unique value will per definition have to be thread-local (if
not, other
threads have a reference to it, and it's not unique). Thus,
when passed to
a functio
On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
In which case we end up with duplicates of all functions to
support both
unique and non-unique parameters. Hence we'd need scope or lent.
OK, I see that we need a way to accept unique values without
enforcing them.
Temporary co
I didn't say an IDE was bad for D, I only said that if you need
an IDE to generate boilerplate for you, then there's something
wrong with the language.
IDE's have lots of other valuable uses.
There is one case of generating boilerplate code which can hardly
be avoided and would at least pa
unique is interesting, and holds many promises. However, its
effects may
be wide-spanning and have many corner case.
In addition to mutability, unique applies to shared/unshared -
a unique
value may safely be moved to another thread.
Pure functions whose parameters are all unique or value t
Just listened to this talk and it made me think about the various
type qualifiers. Has there ever been any thought of introducing a
new type qualifier/attribute, "unique"? I know it already exists
as a standard library class but I think there are several
advantages to having it as a language fe
On Friday, 10 May 2013 at 21:04:32 UTC, Idan Arye wrote:
On Wednesday, 8 May 2013 at 20:11:34 UTC, Idan Arye wrote:
OK, so I'm gonna go ahead and implement it, so I can show by
example that the string solution can be typesafe, scalable and
elegant.
OK, this is a basic implementation:
https://
On Monday, 6 May 2013 at 21:13:24 UTC, Andrej Mitrovic wrote:
On 5/6/13, dsimcha wrote:
On the advice of Walter and Andrei, I've written a blog article
about the low-lock Singleton pattern in D.
Personally this covers it for me:
final abstract class singleton
{
static:
void foo() { }
It's a nice idea but personally I don't like the syntax much, for
example it's completely non-obvious what "true" does when passed
to the singleton mixin, or that the parameters to the property
mixin are "type, name, condition, initial value".
I suppose you could do something like this:
mixin
On Saturday, 4 May 2013 at 23:44:27 UTC, Walter Bright wrote:
On 5/4/2013 4:34 PM, Walter Bright wrote:
And later down the road, maybe even in 2.064, ref will take
r-values
making the new code error because of ambiguity between the two
functions.
Has code breakage ever been taken into account
So just to be clear, "ref" parameters can now take rvalues?
There's one minor problem I see with this:
S currentVar;
void makeCurrent(ref S var) {
currentVar = var;
}
makeCurrent(getRValue());
If "makeCurrent" knew that "var" was an rvalue it could avoid
calling "postblit" on currentVar,
On Monday, 29 April 2013 at 06:26:44 UTC, Walter Bright wrote:
On 4/28/2013 2:05 AM, deadalnix wrote:
On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright
wrote:
On 4/27/2013 2:29 PM, Rob T wrote:
If bools are 1 bit ints, then why do we have 'true' and
'false' as keywords?
Because writi
On Sunday, 28 April 2013 at 05:19:50 UTC, Zach the Mystic wrote:
On Saturday, 27 April 2013 at 23:38:53 UTC, Diggory wrote:
The keyword 'scope' is very well defined at the moment - it
means among other things that the value cannot be returned.
It's only defined very briefly in
I think 'scope' is yet to be fully defined. Returning a
reference doesn't necessarily mean escaping unsafely. The
primary goal is safety. From the perspective of the calling
function, something assigned 'scope' remains in scope even if
it's returned.
The keyword 'scope' is very well defined a
On Saturday, 27 April 2013 at 10:17:58 UTC, deadalnix wrote:
On Friday, 26 April 2013 at 21:37:14 UTC, Walter Bright wrote:
On 4/26/2013 1:59 PM, Andrej Mitrovic wrote:
On 4/26/13, Andrej Mitrovic
wrote:
An even better example:
import std.stdio;
void foo(bool x) { writeln("1"); }
void foo(
scope ref T func(scope ref T t) { return t; }
I think this solves the problem.
It doesn't for several reasons:
- You're completely changing the meaning of "scope" for one
specific case
- This will break DIP25A which only works if scope values cannot
be returned
- "scope" binds to the functio
I don't see myself ever getting on board with this auto-ref
idea. I just
think it's crazy. It makes no sense to me, they are completely
unrelated
concepts. It will only lead to confusion.
I'm back at scope-ref. Kenji is right as far as I'm concerned.
Not to
mention, he actually did the work.
You're just asking for bugs if you allow ref to accept rvalues.
We've had problems like this before when some literals were
treated as lvalues. The behavior of a function which takes its
argument by ref and the behavior of one which takes its
argument by auto ref are fundamentally different.
Whatever the choices are of whether bool is a 1-bit integer or a
a logical true/false value, this should not happen:
enum e = 1;
void main()
{
foo(e); // bool
}
static e = 1;
void main()
{
foo(e); // long
}
The reason being that according to the language spec, the
constant "1" should b
On Wednesday, 24 April 2013 at 20:32:16 UTC, Timon Gehr wrote:
On 04/24/2013 07:07 PM, Diggory wrote:
One way this could be done is by expanding on lazy parameters.
Perhaps
you could specify parameters for a lazy argument, so instead
of always
getting a delegate of type T delegate(), you could
One way this could be done is by expanding on lazy parameters.
Perhaps you could specify parameters for a lazy argument, so
instead of always getting a delegate of type T delegate(), you
could get one of type T delegate(U a, V b).
For example, a parameter could be:
void f(lazy bool exp(int a,
r-values can NEVER be accepted by a ref argument, they don't
'exist', we're
talking about implicitly generated temporaries (which also
addresses the
issues with receiving _explicit_ temp's).
They may be temporary but why should that mean they don't exist.
(wow that's disturbingly close to a har
On Wednesday, 24 April 2013 at 00:54:12 UTC, kenji hara wrote:
2013/4/24 Manu
"The r-value being passed is assigned to a stack allocated
temporary,
which has a lifetime that is identical to any other local
variable, ie, the
lifetime of the function in which it appears."
There, I defined it.
Perhaps you should be able to use void[T] for a set...
If at some point custom attributes will be allowed, @ would be a
nice syntax for that.
Things like @safe could be attributes implemented by the standard
library - would cut down on the number of keywords.
Based on DIP25/35 but slightly simplified, these rules would make
"ref" safe, would minimise code breakage, and only marginally
restricts the usage of "ref". The notion of "lifetime" is purely
a tool for simplifying the explanation of the rules.
Lifetimes
0 = temporary/rvalue
1 = local variabl
1 - 100 of 110 matches
Mail list logo
