Re: Andrei's "Sealed Containers"

On 12/2/2010 11:00 PM, Craig Black wrote: Still working on some details. Thanks for the interest. Thanks for the response. I would be interested to know how far you have gotten and what details are holding up progress, if you don't mind sharing. -Craig What are sealed containers? I guess we

Re: Andrei's "Sealed Containers"

Still working on some details. Thanks for the interest. Thanks for the response. I would be interested to know how far you have gotten and what details are holding up progress, if you don't mind sharing. -Craig

Re: Is opCast need, we have to!

foobar Wrote: > Jesse Phillips Wrote: > > > to!(int)(base!(2)("1010101")); > > semantically this is what i wanted but i still feel that a plain function > would be easier on the eyes. > for instance: > int r = parseInt("101010", 2); > // second parameter is optional and defaults to decimal b

Re: Logical const

Steven Schveighoffer wrote: I have shown examples of how const does not guarantee an object's state doesn't change. Yes, as is well documented, const is a read only view. It is not immutable. That is why immutable is a separate attribute.

Re: tail const

On 12/2/10 6:54 PM, Simen kjaeraas wrote: Michel Fortin wrote: I'm not sure I get the problem. Can you show me in code? const a = map!"a+a"( [1,2,3] ); foreach ( e; a ) { } The foreach fails because popFront is not const. What is needed is for typeof(a) to be Map!("a+a", const(int)[]). IOW

Re: Logical const

Steven Schveighoffer wrote: On Thu, 02 Dec 2010 13:57:04 -0500, Bruno Medeiros wrote: On 29/11/2010 14:56, Steven Schveighoffer wrote: This has been discussed at length on this newsgroup, and I argued for it for a long time. You will not get any traction with Walter, because I've already pr

Re: "Programming in D for C++ Programmers" mistake

Sean Eskapp wrote: There's a significant issue in the "Programming in D for C++ Programmers" article (http://www.digitalmars.com/d/2.0/cpptod.html) The Struct Comparison section is quite wrong. In C++, most structs/classes automatically generate comparison operators. Also, these comparison opera

"Programming in D for C++ Programmers" mistake

There's a significant issue in the "Programming in D for C++ Programmers" article (http://www.digitalmars.com/d/2.0/cpptod.html) The Struct Comparison section is quite wrong. In C++, most structs/classes automatically generate comparison operators. Also, these comparison operators are member funct

Re: tail const

Michel Fortin wrote: I'm not sure I get the problem. Can you show me in code? const a = map!"a+a"( [1,2,3] ); foreach ( e; a ) { } The foreach fails because popFront is not const. What is needed is for typeof(a) to be Map!("a+a", const(int)[]). IOW, is( const(Map!("a+a", int[])) == Map!("a+

Re: Andrei's "Sealed Containers"

On 12/2/10 5:37 PM, Craig Black wrote: Andrei, I long while back I remember you talking about the next big thing being sealed containers and that you would give a presentation on it. Did this fall through or are you still working on it? -Craig Still working on some details. Thanks for the int

Re: Logical const

Don Wrote: > Jonathan M Davis wrote: > > On Thursday, December 02, 2010 01:18:31 Don wrote: > >> Walter Bright wrote: > >>> spir wrote: > What would be the consequences if D had no const, only immutable > (that, IIUC, removes the latter non-guarantee)? > >>> You'd have to write most ever

Re: Is opCast need, we have to!

Jesse Phillips Wrote: > foobar Wrote: > > > how would the to! usage look like with these additions? I suspect at that > > stage the benefits of to! genericity will be lost. > > > > to!(int)("1010101", 2); / base 2 ? > > to!(int)(base!(2)("1010101")); semantically this is what i wanted but i

Andrei's "Sealed Containers"

Andrei, I long while back I remember you talking about the next big thing being sealed containers and that you would give a presentation on it. Did this fall through or are you still working on it? -Craig

Re: debugging code with mixins

== Quote from Trass3r (u...@known.com)'s article > I often use mixins in my code. > This is nice programming-wise but really becomes painful when trying to > debug cause it completely messes up dmd's line numbers. > Is there any solution to this in D? > Could we have some sort of "preprocessed sour

Re: debugging code with mixins

On Thursday, December 02, 2010 14:16:50 Trass3r wrote: > I often use mixins in my code. > This is nice programming-wise but really becomes painful when trying to > debug cause it completely messes up dmd's line numbers. > Is there any solution to this in D? > Could we have some sort of "preprocesse

debugging code with mixins

I often use mixins in my code. This is nice programming-wise but really becomes painful when trying to debug cause it completely messes up dmd's line numbers. Is there any solution to this in D? Could we have some sort of "preprocessed source code" and use that for debugging?

Re: tail const

On 2010-12-02 16:14:58 -0500, "Steven Schveighoffer" said: On Thu, 02 Dec 2010 07:09:27 -0500, Michel Fortin wrote: My only concern with the "const(Object)ref" syntax is that we're reusing 'ref' to denote an object reference with different properties (rebindable, nullable) than what 'ref

Re: [review] new string type

On Wed, 01 Dec 2010 21:13:35 -0500, Ellery Newcomer wrote: On 12/01/2010 03:35 PM, Steven Schveighoffer wrote: On Tue, 30 Nov 2010 18:31:05 -0500, Ellery Newcomer There definitely is value in being able to index and slice into utf strings without resulting in invalid utf, but I think the f

Re: [review] new string type

On Thu, 02 Dec 2010 02:09:51 -0500, Lars T. Kyllingstad wrote: On Wed, 01 Dec 2010 16:44:42 -0500, Steven Schveighoffer wrote: On Tue, 30 Nov 2010 18:34:11 -0500, Lars T. Kyllingstad wrote: On Tue, 30 Nov 2010 13:52:20 -0500, Steven Schveighoffer wrote: On Tue, 30 Nov 2010 13:34:50 -05

Re: [review] new string type

On Thu, 02 Dec 2010 05:08:54 -0500, spir wrote: On Wed, 01 Dec 2010 20:13:35 -0600 Ellery Newcomer wrote: One thing that strikes me, though, if you're going to keep opIndex, is that being able to do foreach(size_t codeuniti, dchar c; s){ } This would yield several times the same code poi

Re: tail const

On Thu, 02 Dec 2010 07:09:27 -0500, Michel Fortin wrote: On 2010-12-02 05:57:18 -0500, Fawzi Mohamed said: well as your are at it I would argue a bit more on the syntax. [...] I suppose that will probably considered too difficult to implement, but I wanted to propose it again because I

Re: DIP9 -- Redo toString API

On Thu, 02 Dec 2010 11:31:49 -0500, Bruno Medeiros wrote: On 21/11/2010 17:21, Don wrote: spir wrote: On Sun, 21 Nov 2010 03:17:57 -0800 Jonathan M Davis wrote: You're not losing _anything_ out of the deal except that you wouldn't do obj.toString(). Instead you'd do to!string(obj). I'm

Re: Logical const

On Thu, 02 Dec 2010 13:57:04 -0500, Bruno Medeiros wrote: On 29/11/2010 14:56, Steven Schveighoffer wrote: This has been discussed at length on this newsgroup, and I argued for it for a long time. You will not get any traction with Walter, because I've already proven that logical const == c

Re: Logical const

On Thu, 02 Dec 2010 12:59:22 -0500, Bruno Medeiros wrote: On 01/12/2010 21:09, Steven Schveighoffer wrote: On Tue, 30 Nov 2010 16:53:14 -0500, Walter Bright wrote: Steven Schveighoffer wrote: If you find the above unsurprising, you are in the minority. I find it surprising, and invalid t

Re: Is opCast need, we have to!

Jesse Phillips wrote: foobar Wrote: how would the to! usage look like with these additions? I suspect at that stage the benefits of to! genericity will be lost. to!(int)("1010101", 2); / base 2 ? to!(int)(base!(2)("1010101")); base!() returns a struct which can be created with strings/int

Re: Logical const

On Wed, 01 Dec 2010 18:34:34 -0500, Walter Bright wrote: Steven Schveighoffer wrote: If I see a function like: void foo(const(C) c); it doesn't mean that foo cannot modify the object referred to by c, it just means that foo won't modify data referenced through c. But a C could store s

Re: Logical const

On Thu, 02 Dec 2010 15:25:49 -0500, Don wrote: Jonathan M Davis wrote: On Thursday, December 02, 2010 01:18:31 Don wrote: Walter Bright wrote: spir wrote: What would be the consequences if D had no const, only immutable (that, IIUC, removes the latter non-guarantee)? You'd have to write mo

Re: Is opCast need, we have to!

foobar Wrote: > how would the to! usage look like with these additions? I suspect at that > stage the benefits of to! genericity will be lost. > > to!(int)("1010101", 2); / base 2 ? to!(int)(base!(2)("1010101")); base!() returns a struct which can be created with strings/int/... and to! can

Re: Logical const

Jonathan M Davis wrote: On Thursday, December 02, 2010 01:18:31 Don wrote: Walter Bright wrote: spir wrote: What would be the consequences if D had no const, only immutable (that, IIUC, removes the latter non-guarantee)? You'd have to write most every function twice, once to take immutable ar

Re: Logical const

Don wrote: Walter Bright wrote: spir wrote: What would be the consequences if D had no const, only immutable (that, IIUC, removes the latter non-guarantee)? You'd have to write most every function twice, once to take immutable args and again for mutable ones. Doesn't 'inout' do almost the

Re: Logical const

On 28/11/2010 14:50, Peter Alexander wrote: 1. I have to change getWorldTransform to be a non-const function that returns a non-const Matrix. 2. renderGameObject needs to be changed to receive a non-const GameObject. 3. I have lost any guarantee that rendering my GameObjects won't destroy them.

Re: Is opCast need, we have to!

On 12/2/2010 10:35 AM, Jonathan M Davis wrote: > On Thursday, December 02, 2010 02:23:23 foobar wrote: >> My suggestion is much simpler than c++. >> the _language_ needs only to provide two operators: >> down cast operator and const cast operator. >> interpret cast is a corner case that can also be

Re: library defined typedef

Bump. We had a thread where a suggestion was made for a library defined typedef: enum Type { Independent, Super, Sub, Parallel, } struct Typedef( T, Type type = Type.Sub, T init = T.init, string _f = __FILE__, int _l = __LINE__ ) { T payload = init; static i

Re: Logical const

On 29/11/2010 14:56, Steven Schveighoffer wrote: This has been discussed at length on this newsgroup, and I argued for it for a long time. You will not get any traction with Walter, because I've already proven that logical const == const, and it still doesn't change his mind. Could you detail

Re: Matlab and D

Has anyone tried to create MEX files or manipulate MAT files with D yet (and thus probably has bindings or a wrapper)? To answer myself: http://bitbucket.org/trass3r/matd/

Re: Logical const

On 29/11/2010 23:04, Walter Bright wrote: Steven Schveighoffer wrote: On Mon, 29 Nov 2010 15:58:10 -0500, Walter Bright wrote: Steven Schveighoffer wrote: Having a logical const feature in D would not be a convention, it would be enforced, as much as const is enforced. I don't understand why

Re: Is opCast need, we have to!

On Thursday, December 02, 2010 02:23:23 foobar wrote: > My suggestion is much simpler than c++. > the _language_ needs only to provide two operators: > down cast operator and const cast operator. > interpret cast is a corner case that can also be implemented as a library > utility. conversions can

Re: Logical const

On Thursday, December 02, 2010 01:18:31 Don wrote: > Walter Bright wrote: > > spir wrote: > >> What would be the consequences if D had no const, only immutable > >> (that, IIUC, removes the latter non-guarantee)? > > > > You'd have to write most every function twice, once to take immutable > > arg

Re: Logical const

On 01/12/2010 21:09, Steven Schveighoffer wrote: On Tue, 30 Nov 2010 16:53:14 -0500, Walter Bright wrote: Steven Schveighoffer wrote: If you find the above unsurprising, you are in the minority. I find it surprising, and invalid that anyone would write code this way. People simply just don't

Re: Is opCast need, we have to!

Jesse Phillips Wrote: > foobar Wrote: > > > > > > - converting to string can have formatting specified > > > > - converting string to numeric types with optional base parameter > > > > - converting integer to floating point specifies > > > > round/floor/ceiling/etc.. > > > > > > This was

Re: Is opCast need, we have to!

Jesse Phillips Wrote: > > besides the overflow issue you have mentioned, I also don't want special > > cases. No implicit conversions should be applied equally everywhere. > > Then be explicit in all of _your_ code. That won't stop others from using > implicit conversion, but you can just assu

Re: DIP9 -- Redo toString API

On 21/11/2010 17:21, Don wrote: spir wrote: On Sun, 21 Nov 2010 03:17:57 -0800 Jonathan M Davis wrote: You're not losing _anything_ out of the deal except that you wouldn't do obj.toString(). Instead you'd do to!string(obj). I'm usually not using toString(), it's supported by the language.

Re: Is opCast need, we have to!

foobar Wrote: > > > - converting to string can have formatting specified > > > - converting string to numeric types with optional base parameter > > > - converting integer to floating point specifies > > > round/floor/ceiling/etc.. > > > > This was kind of my point, to! already specifies

Re: D on Wikipedia [Was: Re: Setting the stack size]

retard wrote: Thu, 02 Dec 2010 12:07:19 +0200, so wrote: I find this D language advocacy in Wikipedia disgusting - clearly, you should document notable features of D, but the main objective cannot be as much visibility as possible. I think that if a language has real technical merits, this

Re: Setting the stack size

On 12/2/2010 10:33 AM, Andrew Wiley wrote: On Wed, Dec 1, 2010 at 7:14 PM, Mike Parker mailto:aldac...@gmail.com>> wrote: On 12/2/2010 6:12 AM, Andrew Wiley wrote: On Wed, Dec 1, 2010 at 2:36 PM, bearophile mailto:bearophileh...@lycos.com>

Re: Principled method of lookup-or-insert in associative arrays?

On 02/12/2010 14:18, Bruno Medeiros wrote: On 20/11/2010 08:07, Andrei Alexandrescu wrote: TDPL has an example that can be reduced as follows: void main() { uint[string] map; foreach (line; stdin.byLine()) { ++map[line]; } } byLine reuses its buffer so it exposes it as char[]. Therefore, attem

Re: Principled method of lookup-or-insert in associative arrays?

On 20/11/2010 08:07, Andrei Alexandrescu wrote: TDPL has an example that can be reduced as follows: void main() { uint[string] map; foreach (line; stdin.byLine()) { ++map[line]; } } byLine reuses its buffer so it exposes it as char[]. Therefore, attempting to use map[line] will fail. The progra

Re: tail const

On 2-dic-10, at 13:09, Michel Fortin wrote: On 2010-12-02 05:57:18 -0500, Fawzi Mohamed said: well as your are at it I would argue a bit more on the syntax. [...] I suppose that will probably considered too difficult to implement, but I wanted to propose it again because I find that it

Re: why a part of D community do not want go to D2 ?

Thu, 02 Dec 2010 13:21:57 +, Bruno Medeiros wrote: > On 30/11/2010 19:02, Stewart Gordon wrote: >> On 30/11/2010 14:13, Bruno Medeiros wrote: >>> On 30/11/2010 14:08, Stewart Gordon wrote: On 29/11/2010 18:30, Bruno Medeiros wrote: >> > Did you mean D2, in "Sick of waiting for D1 to

Re: why a part of D community do not want go to D2 ?

On 30/11/2010 19:02, Stewart Gordon wrote: On 30/11/2010 14:13, Bruno Medeiros wrote: On 30/11/2010 14:08, Stewart Gordon wrote: On 29/11/2010 18:30, Bruno Medeiros wrote: Did you mean D2, in "Sick of waiting for D1 to be finished." ? I don't know what you mean I meant: did you mean

Re: Interval foreach iteration variable

Jonathan M Davis: > but I don't agree that it should not be possible to do it by ref as your post > implies. My post doesn't talk about "ref", the "ref" is just present in issue 5306 that is about a related but different thing :-) Bye, bearophile

Re: D's greatest mistakes

Walter: > There are a thousand languages out there. I could spend multiple lifetimes > studying them, and then have to start all over with the new crop of > languages, > and accomplish absolutely nothing. It's a matter of balance. If you want to design something new you need to keep yourself

Re: D on Wikipedia [Was: Re: Setting the stack size]

There's a language independentintroduction and examples in various languages http://en.wikipedia.org/wiki/Man_or_boy_test You are right. More text about D isn't better I find this D language advocacy in Wikipedia disgusting I absolutely agree on these two points, but it is not what i meant

Re: tail const

On 2010-12-02 05:57:18 -0500, Fawzi Mohamed said: well as your are at it I would argue a bit more on the syntax. [...] I suppose that will probably considered too difficult to implement, but I wanted to propose it again because I find that it is the most clean solution conceptually. It is

Re: Logical const

On 1-dic-10, at 22:18, Steven Schveighoffer wrote: On Wed, 01 Dec 2010 11:49:36 -0500, so wrote: On Wed, 01 Dec 2010 18:38:23 +0200, so wrote: Since i called it a bad design, i am entitled to introduce a better design. interface renderer { void draw(rect rects, size_t n); } cl

Re: Logical const

On 1-dic-10, at 04:52, Jesse Phillips wrote: Fawzi Mohamed Wrote: The thing is that a lazy structure is very useful in functional programming. A lazy evaluation is something that should be possible using pure and immutable. I find it jarring that to do that one has to avoid D pure and immut

Re: D on Wikipedia [Was: Re: Setting the stack size]

Thu, 02 Dec 2010 12:07:19 +0200, so wrote: >> I'd introduce the templates using code written in C++ and then list the >> differences between C++ and D. After all, C++ and C++ TMP are widely >> known. Even I have few books of them in my bookshelf and ps/pdf papers >> discussing C++ TMP. There aren'

Re: tail const

On 1-dic-10, at 12:10, spir wrote: On Tue, 30 Nov 2010 23:57:04 +0100 Fawzi Mohamed wrote: Speaking about D mistakes Steve spoke about missing tail const. I was thinking about this, and I fully agree that it is a hole. I don't know if it was already discussed, but I was thinking that one cou

Re: tail const

On 1-dic-10, at 20:07, Michel Fortin wrote: On 2010-12-01 09:37:08 -0500, Michel Fortin said: On 2010-12-01 06:17:24 -0500, Jonathan M Davis said: I proposed the following a while ago. First allow the class reference to (optionally) be made explicit: C a; // mutable reference to m

Re: Is opCast need, we have to!

Jonathan M Davis Wrote: > On Wednesday, December 01, 2010 14:32:12 bearophile wrote: > > foobar: > > > 1. static_cast: > > > a. Remove ALL implicit coercions inherited from c such as double -> > > > int, b. I don't see the need for an operator for conversions since > > > they can have differ

Re: Is opCast need, we have to!

Jesse Phillips Wrote: > foobar Wrote: > > > IMHO, coercions in D should be redesigned. They are a tiny bit better than > > C but C is a weekly (and poorly) typed language. I personally prefer the > > properly strongly typed ML family of languages. > > > > My preference is as follows: > > 1. st

Re: D on Wikipedia [Was: Re: Setting the stack size]

I'd introduce the templates using code written in C++ and then list the differences between C++ and D. After all, C++ and C++ TMP are widely known. Even I have few books of them in my bookshelf and ps/pdf papers discussing C++ TMP. There aren't any books or peer reviewed articles about D's metapro

Re: [review] new string type

On Wed, 01 Dec 2010 20:13:35 -0600 Ellery Newcomer wrote: > One thing that strikes me, though, if you're going to keep opIndex, is > that being able to do > > foreach(size_t codeuniti, dchar c; s){ > > } This would yield several times the same code point / dchar, or do i misinterpret? Denis

Re: D on Wikipedia [Was: Re: Setting the stack size]

Thu, 02 Dec 2010 11:10:33 +0200, so wrote: >> http://en.wikipedia.org/w/index.php? >> title=Template_metaprogramming&diff=64616972&oldid=64616688 >> >> The discussion page mentions it doesn't add any value and I can't >> disagree. > > They might be clueless to say that, but you? I agree static-i

Re: Logical const

Walter Bright wrote: spir wrote: What would be the consequences if D had no const, only immutable (that, IIUC, removes the latter non-guarantee)? You'd have to write most every function twice, once to take immutable args and again for mutable ones. Doesn't 'inout' do almost the same thing?

Re: D on Wikipedia [Was: Re: Setting the stack size]

If Wikipedia is hostile to D What is this supposed to mean? Who is Mr Wikipedia not liking D? (I'm not joking -- I would like to know things about wikipedia I do not know yet.) What is this Mr gamedev not liking D? Not hard to check. -- Using Opera's revolutionary email client: http://www

Re: D on Wikipedia [Was: Re: Setting the stack size]

http://en.wikipedia.org/w/index.php? title=Template_metaprogramming&diff=64616972&oldid=64616688 The discussion page mentions it doesn't add any value and I can't disagree. They might be clueless to say that, but you? Resists? You weren't able to fill it with D propaganda? It already lists th

Re: D on Wikipedia [Was: Re: Setting the stack size]

On Thu, 2 Dec 2010 05:13:27 + (UTC) Justin C Calvarese wrote: > If Wikipedia is hostile to D What is this supposed to mean? Who is Mr Wikipedia not liking D? (I'm not joking -- I would like to know things about wikipedia I do not know yet.) Denis -- -- -- -- -- -- -- vit esse estrany ☣ s

Re: D on Wikipedia [Was: Re: Setting the stack size]

On Wed, 01 Dec 2010 20:52:47 -0500 bearophile wrote: > D is good for allowing to add the last values to the results table for n up > to 25: > http://en.wikipedia.org/wiki/Man_or_boy_test > The reference to D was later removed by someone, of course. > They have even removed D examples from the te

Re: D on Wikipedia [Was: Re: Setting the stack size]

Wed, 01 Dec 2010 20:52:47 -0500, bearophile wrote: >> On Windows with DMD this is how to set the max stack size to about 1.5 >> GB of the "test.d" module: dmd -L/STACK:15 test.d > > D is good for allowing to add the last values to the results table for n > up to 25: http://en.wikipedia.or

Re: D's greatest mistakes

architect wrote: You should study Eiffel that much. There are a thousand languages out there. I could spend multiple lifetimes studying them, and then have to start all over with the new crop of languages, and accomplish absolutely nothing.

Re: D on Wikipedia [Was: Re: Setting the stack size]

The reference to D was later removed by someone, of course. They have even removed D examples from the template metaprogramming page, etc. The page about CTFE resists still: Even CTFE example is hostile. If i search line/sphere ... first thing i see in wikipedia is a almost perfect computer

Re: Should pure functions be prevented from reading changeable immutable static variables?

Bruno Medeiros wrote: On 06/11/2010 01:32, Don wrote: Pure functions are allowed to read immutable global variables. Currently, this even includes globals which are initialized from inside 'static this()'. Here's an example of how this can be a problem: immutable int unstable; pure int buggy()