You missed the point. The case with dynamic libraries is just too
obvious: they're "dynamic" for a reason. The case of base classes not
knowing their derived classes is also kinda obvious because the
mutable aliases would allow for derived classes to add themselves to
the tuple by mixin in some com
On Thursday, December 29, 2011 10:23:11 Gor Gyolchanyan wrote:
> The mutability of compile-time data would essentially enable fully
> imperative compile-time computation. Right now it's almost purely
> functional with the small exception of CTFE functions. Sometimes
> functional style can't do the
On Thursday, December 29, 2011 00:06:57 Brad Anderson wrote:
> Forgive me if this is a silly question but a conversation in IRC got me
> wondering if compiler could check for shared/__gshared use (and any other
> thread unsafe operation) in each unittest and run those that aren't using
> them concu
The mutability of compile-time data would essentially enable fully
imperative compile-time computation. Right now it's almost purely
functional with the small exception of CTFE functions. Sometimes
functional style can't do the trick. For instance, you can't make a
template which "returns" a TypeTu
On Thursday, 29 December 2011 at 07:07:10 UTC, Brad Anderson
wrote:
Forgive me if this is a silly question but a conversation in
IRC got me
wondering if compiler could check for shared/__gshared use (and
any other
thread unsafe operation) in each unittest and run those that
aren't using
them co
On Wed, Dec 28, 2011 at 10:11 PM, Jonathan M Davis wrote:
> On Wednesday, December 28, 2011 23:07:51 Jacob Carlborg wrote:
> > I think it is, don't know what others think. What it does is it catches
> > AssertErrors so other unit tests can continue to run and then gives a
> > nice report at the en
On 12/28/2011 10:33 PM, Jakob Ovrum wrote:
I don't think this is a problem you can solve without educating people. They
will need to know a thing or two about how UTF works to know the performance
implications of many of the "safe" ways to handle UTF strings. Further, for much
use of Unicode stri
On 12/28/2011 10:08 PM, Andrei Alexandrescu wrote:
The only solution is to explain Walter no other programmer in the world codes
UTF like him. Really. I emulate that sometimes (learned from him) but I see code
from hundreds of people day in and day out - it's never like his.
Once we convince him
I implemented a base class for reference couting. The problem now is
that because the RemoveReference function is a public one and might
destroy and delete the object when the reference count drops to 0 the D
invariant handler will crash because it gets called always at the end of
that function
On Wednesday, 28 December 2011 at 22:39:15 UTC, Timon Gehr wrote:
On 12/28/2011 11:12 PM, foobar wrote:
On Wednesday, 28 December 2011 at 21:17:49 UTC, Timon Gehr
wrote:
I was educated enough not to make that mistake, because I
read the
entire language specification before deciding the langua
David Nadlinger wrote:
> Could you show a few examples? I'm just curious, because I wrote a
> sizable chunk of D code, often incorporating some form of compile time
> magic, and never felt the need for it.
I'd rather avoid that because code i'm writing isn't a state of art, so you
might neglect my
On Thursday, December 29, 2011 07:33:28 Jakob Ovrum wrote:
> I don't think this is a problem you can solve without educating
> people. They will need to know a thing or two about how UTF works
> to know the performance implications of many of the "safe" ways
> to handle UTF strings. Further, for mu
On Thursday, 29 December 2011 at 06:08:05 UTC, Andrei
Alexandrescu wrote:
On 12/28/11 11:36 PM, Walter Bright wrote:
On 12/28/2011 8:32 PM, Adam D. Ruppe wrote:
On Thursday, 29 December 2011 at 04:17:37 UTC, Andrei
Alexandrescu wrote:
If we have two facilities (string and e.g. String) we've
lo
On 12/29/11 12:01 AM, Adam D. Ruppe wrote:
On Thursday, 29 December 2011 at 05:37:00 UTC, Walter Bright wrote:
I've seen the damage done in C++ with multiple string types. Being
able to convert from one to the other doesn't help much.
Note that I'm on your side here re strings, but you're
unde
On 12/28/11 11:36 PM, Walter Bright wrote:
On 12/28/2011 8:32 PM, Adam D. Ruppe wrote:
On Thursday, 29 December 2011 at 04:17:37 UTC, Andrei Alexandrescu wrote:
If we have two facilities (string and e.g. String) we've lost. We'd
need to
slowly change the built-in string type.
Have you actuall
On Thursday, 29 December 2011 at 05:37:00 UTC, Walter Bright
wrote:
I've seen the damage done in C++ with multiple string types.
Being able to convert from one to the other doesn't help much.
Note that I'm on your side here re strings, but you're
underselling the D language too! These conversio
On 12/28/2011 8:32 PM, Adam D. Ruppe wrote:
On Thursday, 29 December 2011 at 04:17:37 UTC, Andrei Alexandrescu wrote:
If we have two facilities (string and e.g. String) we've lost. We'd need to
slowly change the built-in string type.
Have you actually tried to do it?
I've seen the damage don
On 12/29/11 6:18 AM, Mariusz Gliwiński wrote:
Andrei Alexandrescu wrote:
I don't think such a feature has a huge potential use. I honestly think
it's a "meh" feature. It's a feature for defining elaborate literals,
and for that we have the shock and awe of mixin and CTFE.
Actually, i already n
On 12/28/2011 9:18 PM, Mariusz Gliwiński wrote:
For me, question would be not "if it's useful", but "is it easy to implement
and if it's not hurting compiler performance too much".
I beg to differ. A feature should be "why", not "why not". Otherwise, we wind up
with a complex boatload of semi-
On Wednesday, December 28, 2011 23:07:51 Jacob Carlborg wrote:
> I think it is, don't know what others think. What it does is it catches
> AssertErrors so other unit tests can continue to run and then gives a
> nice report at the end.
I'm against it. I think that the compiler/runtime should be fix
On Thursday, 29 December 2011 at 04:17:37 UTC, Andrei
Alexandrescu wrote:
If we have two facilities (string and e.g. String) we've lost.
We'd need to slowly change the built-in string type.
Have you actually tried to do it? Thanks to alias this, the custom
string can be used with existing std.s
Andrei Alexandrescu wrote:
> I don't think such a feature has a huge potential use. I honestly think
> it's a "meh" feature. It's a feature for defining elaborate literals,
> and for that we have the shock and awe of mixin and CTFE.
Actually, i already needed it few times in my D project (and stil
On 12/28/11 4:18 PM, foobar wrote:
On Wednesday, 28 December 2011 at 21:57:00 UTC, Andrei Alexandrescu wrote:
On 12/28/11 1:48 PM, foobar wrote:
On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei Alexandrescu
wrote:
On 12/28/11 1:18 PM, foobar wrote:
That's a good idea which I wonder abou
On 12/28/11 4:54 PM, Gor Gyolchanyan wrote:
I think you are, because this depends on syntax; blank lines between
them would break it. Still there would be a huge potential use for
that feature.
I don't think such a feature has a huge potential use. I honestly think
it's a "meh" feature. It's a
"Peter Alexander" wrote in message
news:jdct6a$2230$1...@digitalmars.com...
> How would that work? opDispatch already has variadic templates for the
> normal function parameters. Make opDispatch a template inside a template?
I suppose that's what this is for.
http://d.puremagic.com/issues/show_
On 12/29/11 3:46 AM, Timon Gehr wrote:
My point is, without named arguments you can improve the names at any
time. With named arguments, you are stuck and have to get it right upfront.
My point is, without positional arguments you can improve the ordering
at any time. With positional arguments
Timon Gehr:
> My point is, without named arguments you can improve the names at any
> time. With named arguments, you are stuck and have to get it right upfront.
I think library code doesn't change argument names often, and when this happens
I have suggested a way to deprecate argument names. S
Along the time time I have put in Bugzilla a good amount of code for Phobos.
In Bugzilla I have an enhancement request that asks to turn std.random.dice
into a range:
http://d.puremagic.com/issues/show_bug.cgi?id=5849
Through Reddit I have found an efficient O(1) weighted choice:
http://www.keit
On 12/29/2011 03:38 AM, bearophile wrote:
Timon Gehr:
On 12/29/2011 02:04 AM, Derek wrote:
On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr wrote:
Having parameter names contribute to the interface means that all
developers need to spend time thinking about the best possible names
for their f
Timon Gehr:
> On 12/29/2011 02:04 AM, Derek wrote:
> > On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr wrote:
> >
> >> Having parameter names contribute to the interface means that all
> >> developers need to spend time thinking about the best possible names
> >> for their function parameters.
> >
On 12/29/2011 02:02 AM, so wrote:
On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr wrote:
On 12/29/2011 12:58 AM, so wrote:
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr
wrote:
The moment NP by default is introduced is the moment all parameter
names in all libraries are set in stone.
This
On 12/29/2011 02:04 AM, Derek wrote:
On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr wrote:
Having parameter names contribute to the interface means that all
developers need to spend time thinking about the best possible names
for their function parameters.
And that's a bad thing, right?
If
phobos currently checks "static interfaces" with something like
https://github.com/D-Programming-Language/phobos/blob/master/std/range.d#L213
I wonder if stuff like that could be unified by only defining
normal interfaces and "automating" the static checking with
something like
template impl
On Thu, 29 Dec 2011 12:02:28 +1100, so wrote:
Show me any library code from any language where library writer is not
already "aware" their argument names define their function.
Supporting example:
int find( T needle, T[] haystack)
As a side effect, it might even help prevent the unnec
On Wed, 28 Dec 2011 19:51:42 +0100, Andrei Alexandrescu
wrote:
On 12/28/11 12:22 PM, Martin Nowak wrote:
On Wed, 28 Dec 2011 15:00:10 +0100, Gor Gyolchanyan
wrote:
This is something I was thinking about for a long time now.
There seems to be absolutely no difference between T, const(T) a
On Thu, 29 Dec 2011 10:48:57 +1100, Timon Gehr wrote:
Having parameter names contribute to the interface means that all
developers need to spend time thinking about the best possible names for
their function parameters.
And that's a bad thing, right?
Named parameters do have the issue tha
On Thu, 29 Dec 2011 02:14:18 +0200, Timon Gehr wrote:
On 12/29/2011 12:58 AM, so wrote:
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr
wrote:
The moment NP by default is introduced is the moment all parameter
names in all libraries are set in stone.
This is completely false. NP affects
On 12/29/2011 12:58 AM, so wrote:
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr wrote:
The moment NP by default is introduced is the moment all parameter
names in all libraries are set in stone.
This is completely false. NP affects only those that "want" to use it,
no one else. Again, no on
On Thu, 29 Dec 2011 01:58:46 +0200, so wrote:
He doesn't need to remember, compiler does that for him but only for him
:)
As it turns out compiler don't give a damn about him either.
On Thu, 29 Dec 2011 01:48:57 +0200, Timon Gehr wrote:
The moment NP by default is introduced is the moment all parameter names
in all libraries are set in stone.
This is completely false. NP affects only those that "want" to use it, no
one else. Again, no one.
It is just like inline asm.
Timon Gehr:
> Having parameter names contribute to the interface means that all
> developers need to spend time thinking about the best possible names for
> their function parameters.
And this is a good thing :-) It helps you understand the function purpose
better.
Bye,
bearophile
On Wednesday, 28 December 2011 at 20:58:33 UTC, Jonathan M Davis
wrote:
Since they affect the API, they _do_ hurt
In my web.d, I support named and positional parameters for
remote calls.
I almost always use the positional parameters exactly because
they are not affected by name changes in the
On Wednesday, 28 December 2011 at 22:57:29 UTC, bearophile wrote:
(while I have not written a significant amount of
functional-style code in Javascript)
It looks fine if you use named functions or a little whitespace
around the literals (same as D!).
On 12/29/2011 12:29 AM, so wrote:
On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr wrote:
On 12/28/2011 11:34 PM, so wrote:
If you change "anything" in your interface, it is already a breaking
change.
That is why it is desirable to not let parameter names contribute to
the interface. Jonathan
Jonathan M Davis:
> The primary reason that I really don't like named arguments is the fact that
> the names of the parameters become part of the API.
Sometimes I don't mind to make the names part of the API.
And as you remember we have suggested an idea adapted from Scala.
void foo(int x) {}
v
On Thu, 29 Dec 2011 00:48:54 +0200, Timon Gehr wrote:
On 12/28/2011 11:34 PM, so wrote:
If you change "anything" in your interface, it is already a breaking
change.
That is why it is desirable to not let parameter names contribute to the
interface. Jonathan definitely has a point against m
Andrei Alexandrescu:
> one good thing that could come out of this thread
> is abolition (through however slow a deprecation path) of s.length and
> s[i] for narrow strings. Requiring s.rep.length instead of s.length and
> s.rep[i] instead of s[i] would improve the quality of narrow strings
> treme
deadalnix:
> bearophile:
>> In my opinion the most important reason for the introduction of
>> this anonymous function syntax is that it makes D functional-style
>> code (and generally code that uses lot of callbacks) less noisy,
>> so it makes it more easy to write and read.
> Both argument are
I think you are, because this depends on syntax; blank lines between
them would break it. Still there would be a huge potential use for
that feature.
On Wed, Dec 28, 2011 at 10:51 PM, Andrei Alexandrescu
wrote:
> On 12/28/11 12:22 PM, Martin Nowak wrote:
>>
>> On Wed, 28 Dec 2011 15:00:10 +0100,
On Wed, 28 Dec 2011 14:06:06 +0200, Peter Alexander
wrote:
string is immutable(char)[]
I rarely *ever* need an immutable string. What I usually need is
const(char)[]. I'd say 99%+ of the time I need only a const string.
This is quite irritating because "string" is the most convenient and
On 12/28/2011 11:34 PM, so wrote:
If you change "anything" in your interface, it is already a breaking
change.
That is why it is desirable to not let parameter names contribute to the
interface. Jonathan definitely has a point against making all parameters
named parameters by default.
From
On 12/28/2011 11:12 PM, foobar wrote:
On Wednesday, 28 December 2011 at 21:17:49 UTC, Timon Gehr wrote:
I was educated enough not to make that mistake, because I read the
entire language specification before deciding the language was awesome
and downloading the compiler. I find it strange that
On Wed, 28 Dec 2011 22:57:32 +0200, Jonathan M Davis
wrote:
I'd hate to have a function like
void func(float x, float y);
where calling it
func(1.0, 2.0);
and
func(y : 1.0, x : 2.0);
don't do the same thing. All of a sudden, I have to pay attention to what
names the arguments were given
On 2011-12-28 22:19, jdrewsen wrote:
On Wednesday, 28 December 2011 at 16:01:50 UTC, Jacob Carlborg wrote:
On 2011-12-27 03:01, dsimcha wrote:
By a vote of 14-0, Jonas Drewsen's CURL wrapper (std.net.curl) has been
accepted into Phobos. Thanks to Jonas for his hard work and his
persistence thro
On Wednesday, 28 December 2011 at 21:57:00 UTC, Andrei
Alexandrescu wrote:
On 12/28/11 1:48 PM, foobar wrote:
On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei
Alexandrescu wrote:
On 12/28/11 1:18 PM, foobar wrote:
That's a good idea which I wonder about its implementation
strategy.
Imp
On Wednesday, 28 December 2011 at 21:17:49 UTC, Timon Gehr wrote:
I was educated enough not to make that mistake, because I read
the entire language specification before deciding the language
was awesome and downloading the compiler. I find it strange
that the product should be made less usab
On 2011-12-28 19:43, dsimcha wrote:
On Wednesday, 28 December 2011 at 16:01:50 UTC, Jacob Carlborg wrote:
Running the unit tests:
./unittest.sh
Use "make" to compile the library or create an executable using rdmd.
A few things to think about that need to be resolved:
* This is quite a large l
On 2011-12-28 18:54, Timon Gehr wrote:
On 12/28/2011 05:59 PM, Jacob Carlborg wrote:
On 2011-12-28 13:54, bearophile wrote:
Timon Gehr:
=> expr
should imo be a shorthand for
() => expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
functi
On 2011-12-28 18:15, deadalnix wrote:
Le 28/12/2011 13:54, bearophile a écrit :
Timon Gehr:
=> expr
should imo be a shorthand for
() => expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases syn
On 12/28/11 1:48 PM, foobar wrote:
On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei Alexandrescu wrote:
On 12/28/11 1:18 PM, foobar wrote:
That's a good idea which I wonder about its implementation strategy.
Implementation would entail a change in the compiler.
Andrei
Why? D should b
On Monday, 26 December 2011 at 17:37:17 UTC, Piotr Szturmaj wrote:
Yes. Here are the results: http://pastebin.com/rD8kiaQy. This
is observed only with Windows DMD.
I'd be more interested in seeing the code.
I've done some more research on this. In release builds, DMD on
Windows emits a memcpy
On 12/28/2011 09:57 PM, Jonathan M Davis wrote:
On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:
I also don't think that they add much unless you have functions with way
too many parameters, and those sorts of functions shouldn't be
happening anyway. And I don't like the additional com
On Wednesday, 28 December 2011 at 20:49:54 UTC, Jonathan M Davis
wrote:
On Wednesday, December 28, 2011 19:25:15 Jakob Ovrum wrote:
Also, 'in char[]', which is conceptually much safer, isn't that
much longer to type.
It would be cool if 'scope' was actually implemented apart from
an optimizatio
On Wednesday, 28 December 2011 at 16:01:50 UTC, Jacob Carlborg
wrote:
On 2011-12-27 03:01, dsimcha wrote:
By a vote of 14-0, Jonas Drewsen's CURL wrapper (std.net.curl)
has been
accepted into Phobos. Thanks to Jonas for his hard work and his
persistence through the multiple rounds of review tha
Apparently my previous post was lost. Apologies if this comes out twice.
On 12/28/2011 09:39 PM, Jonathan M Davis wrote:
On Wednesday, December 28, 2011 21:25:39 Timon Gehr wrote:
Why? char and wchar are unicode code units, ubyte/ushort are unsigned
integrals. It is clear that char/wchar are a
On 2011-12-28 18:15, deadalnix wrote:
Le 28/12/2011 13:54, bearophile a écrit :
Timon Gehr:
=> expr
should imo be a shorthand for
() => expr.
It saves some ((())(()))().
It saves few (), but zero argument lambdas aren't that common in my
functional-style code, and I think it decreases syn
On Wednesday, December 28, 2011 21:44:01 Timon Gehr wrote:
> > I also don't think that they add much unless you have functions with way
> > too many parameters, and those sorts of functions shouldn't be
> > happening anyway. And I don't like the additional complication of the
> > possibility of reo
On Wednesday, December 28, 2011 19:25:15 Jakob Ovrum wrote:
> Also, 'in char[]', which is conceptually much safer, isn't that
> much longer to type.
>
> It would be cool if 'scope' was actually implemented apart from
> an optimization though.
in char[] is _not_ safer than immutable(char)[]. In fa
On 12/28/2011 09:25 PM, Jonathan M Davis wrote:
On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:
I can understand how Jonathan has no problem writing verbose code, but
I'd rather not have to write enums all over the place just to use a
true/false flag that is obvious at the call s
On Wednesday, December 28, 2011 10:27:15 Andrei Alexandrescu wrote:
> I'm afraid you're wrong here. The current setup is very good, and much
> better than one in which "string" would be an alias for const(char)[].
>
> The problem is escaping. A function that transitorily operates on a
> string ind
On Wednesday, December 28, 2011 21:25:39 Timon Gehr wrote:
> Why? char and wchar are unicode code units, ubyte/ushort are unsigned
> integrals. It is clear that char/wchar are a better match.
It's an issue of the correct usage being the easy path. As it stands, it's
incredibly easy to use narrow
On 12/28/2011 08:00 PM, Andrei Alexandrescu wrote:
On 12/28/11 12:46 PM, Walter Bright wrote:
On 12/28/2011 10:35 AM, Peter Alexander wrote:
On 28/12/11 6:15 PM, Walter Bright wrote:
If such a change is made, then people will use const string when they
mean immutable, and the values underneath
On Wednesday, December 28, 2011 15:57:42 Andrej Mitrovic wrote:
> I can understand how Jonathan has no problem writing verbose code, but
> I'd rather not have to write enums all over the place just to use a
> true/false flag that is obvious at the call site compared to calls
> like this:
>
> showW
On Wednesday, 28 December 2011 at 20:01:15 UTC, foobar wrote:
I'd also like a transition of the string related functions to
this type. the previous ones can remain as simple
wrappers/aliases/whatever for backwards compatibility.
I actually like strings just the way they are... but if
we had to
On 12/28/2011 08:55 PM, foobar wrote:
On Wednesday, 28 December 2011 at 19:38:53 UTC, Timon Gehr wrote:
[snip]
I'm all for making string a properly encapsulated type.
In what way would the proposed change improve encapsulation, and why
would it even be desirable for such a basic data structur
On Wednesday, 28 December 2011 at 19:48:28 UTC, Adam D. Ruppe
wrote:
On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei
Alexandrescu wrote:
Implementation would entail a change in the compiler.
I don't think I agree. Wouldn't something like this work?
===
struct string {
immutable(
On 12/28/2011 06:40 PM, Andrei Alexandrescu wrote:
On 12/28/11 11:11 AM, Walter Bright wrote:
On 12/28/2011 4:06 AM, Peter Alexander wrote:
I rarely *ever* need an immutable string. What I usually need is
const(char)[].
I'd say 99%+ of the time I need only a const string.
I have a very differ
On Wednesday, 28 December 2011 at 19:38:53 UTC, Timon Gehr wrote:
[snip]
I'm all for making string a properly encapsulated type.
In what way would the proposed change improve encapsulation,
and why would it even be desirable for such a basic data
structure?
I'm not sure what are you asking
On 12/28/2011 08:29 PM, Andrei Alexandrescu wrote:
On 12/28/11 1:17 PM, Robert Jacques wrote:
Would slicing, i.e. s[i..j] still be valid?
No, only s.rep[i .. j].
That does not do the right thing. It would look more like
cast(string)s.rep[i .. j].
If so, what would be the
recommended way
On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei
Alexandrescu wrote:
Implementation would entail a change in the compiler.
I don't think I agree. Wouldn't something like this work?
===
struct string {
immutable(char)[] rep;
alias rep this;
auto opAssign(immutable(ch
On Wednesday, 28 December 2011 at 19:30:04 UTC, Andrei
Alexandrescu wrote:
On 12/28/11 1:18 PM, foobar wrote:
That's a good idea which I wonder about its implementation
strategy.
Implementation would entail a change in the compiler.
Andrei
Why? D should be plenty powerful to implement this
On 12/28/2011 08:30 PM, Andrei Alexandrescu wrote:
On 12/28/11 1:18 PM, foobar wrote:
That's a good idea which I wonder about its implementation strategy.
Implementation would entail a change in the compiler.
Andrei
Special casing char[] and wchar[] in the language would be extremely
ugly
On 12/28/2011 08:18 PM, foobar wrote:
On Wednesday, 28 December 2011 at 19:00:53 UTC, Andrei Alexandrescu wrote:
On 12/28/11 12:46 PM, Walter Bright wrote:
On 12/28/2011 10:35 AM, Peter Alexander wrote:
On 28/12/11 6:15 PM, Walter Bright wrote:
If such a change is made, then people will use c
On 12/28/11 1:18 PM, foobar wrote:
That's a good idea which I wonder about its implementation strategy.
Implementation would entail a change in the compiler.
Andrei
On 12/28/11 1:17 PM, Robert Jacques wrote:
Would slicing, i.e. s[i..j] still be valid?
No, only s.rep[i .. j].
If so, what would be the
recommended way of finding i and j?
find, findSplit etc. from std.algorithm, std.utf functions etc.
Andrei
Most common to me buffer reuse. I'll read a line of a file into a buffer,
operate on it, then read the next line into the same buffer. If references to
the buffer may escape, it's obviously unsafe to cast to immutable.
Sent from my iPhone
On Dec 28, 2011, at 9:11 AM, Walter Bright wrote:
> O
On Wednesday, 28 December 2011 at 19:00:53 UTC, Andrei
Alexandrescu wrote:
On 12/28/11 12:46 PM, Walter Bright wrote:
On 12/28/2011 10:35 AM, Peter Alexander wrote:
On 28/12/11 6:15 PM, Walter Bright wrote:
If such a change is made, then people will use const string
when they
mean immutable, a
On Wed, 28 Dec 2011 11:00:52 -0800, Andrei Alexandrescu
wrote:
On 12/28/11 12:46 PM, Walter Bright wrote:
On 12/28/2011 10:35 AM, Peter Alexander wrote:
On 28/12/11 6:15 PM, Walter Bright wrote:
If such a change is made, then people will use const string when they
mean immutable, and the val
On 12/28/2011 10:56 AM, Andrei Alexandrescu wrote:
Yes. Contrary to the OP, I don't think it's fair to dismiss a valid concern by
framing it as a user education issue. It's has very often been aired in the
olden days of C++, and never in a winning argument. (Right off the bat -
auto_ptr.)
And
On 12/28/11 12:46 PM, Walter Bright wrote:
On 12/28/2011 10:35 AM, Peter Alexander wrote:
On 28/12/11 6:15 PM, Walter Bright wrote:
If such a change is made, then people will use const string when they
mean immutable, and the values underneath are not guaranteed to be
consistent.
Then people
On 12/28/11 12:46 PM, Walter Bright wrote:
On 12/28/2011 10:35 AM, Peter Alexander wrote:
On 28/12/11 6:15 PM, Walter Bright wrote:
If such a change is made, then people will use const string when they
mean immutable, and the values underneath are not guaranteed to be
consistent.
Then people
On 12/28/11 12:22 PM, Martin Nowak wrote:
On Wed, 28 Dec 2011 15:00:10 +0100, Gor Gyolchanyan
wrote:
This is something I was thinking about for a long time now.
There seems to be absolutely no difference between T, const(T) and
immutable(T) if T is a compile-time value (a enum or a local in C
On 12/28/2011 10:35 AM, Peter Alexander wrote:
On 28/12/11 6:15 PM, Walter Bright wrote:
If such a change is made, then people will use const string when they
mean immutable, and the values underneath are not guaranteed to be
consistent.
Then people should learn what const and immutable mean!
On Wednesday, 28 December 2011 at 16:01:50 UTC, Jacob Carlborg
wrote:
Running the unit tests:
./unittest.sh
Use "make" to compile the library or create an executable using
rdmd.
A few things to think about that need to be resolved:
* This is quite a large library and I really don't want to p
On 12/28/2011 07:15 PM, deadalnix wrote:
The syntax to do such a thing is more verbose in javascript. So
definitively, this is a nice syntax, but this isn't that ground
breaking, and this isn't even required for people to use this type of
constructs.
People keep complaining about the verbosit
On Wednesday, 28 December 2011 at 16:27:15 UTC, Andrei
Alexandrescu wrote:
So immutable(char)[] is the best choice for a correct string
abstraction compared against both char[] and const(char)[]. In
fact it's in a way good that const(char)[] takes longer to
type, because it also carries larger
On 28/12/11 6:15 PM, Walter Bright wrote:
On 12/28/2011 10:07 AM, Peter Alexander wrote:
The question is whether string should alias immutable(char)[] or
const(char)[].
In my experience (which is echoed in Phobos) is that const(char)[] is
used much
more often than immutable(char)[], so it should
On Wed, 28 Dec 2011 15:00:10 +0100, Gor Gyolchanyan
wrote:
This is something I was thinking about for a long time now.
There seems to be absolutely no difference between T, const(T) and
immutable(T) if T is a compile-time value (a enum or a local in CTFE).
The possibility to mutate compile-t
On 28/12/11 6:03 PM, Timon Gehr wrote:
On 12/28/2011 07:07 PM, Peter Alexander wrote:
On 28/12/11 5:16 PM, Walter Bright wrote:
On 12/28/2011 5:16 AM, Peter Alexander wrote:
Any time you want to create a string without allocating memory.
char[N] buffer;
// write into buffer
// try to use buff
On 12/28/2011 10:07 AM, Peter Alexander wrote:
On 28/12/11 5:16 PM, Walter Bright wrote:
On 12/28/2011 5:16 AM, Peter Alexander wrote:
Any time you want to create a string without allocating memory.
char[N] buffer;
// write into buffer
// try to use buffer as string
Is the buffer ever going
1 - 100 of 149 matches
Mail list logo
