www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Does D have too many features?

reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei and I had a fun discussion last night about this question. The idea was 
which features in D are redundant and/or do not add significant value?

A couple already agreed upon ones are typedef and the cfloat, cdouble and creal 
types.

What's your list?
Apr 28 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 28/04/2012 20:47, Walter Bright a écrit :
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

I think many D features come from the lack of AOP in D. I already mentioned that in some other thread. I would also mention the is expression which does way too many stuffs and many of them are not usefull or counter intuitive and may be replaced by lib support in std.traits .
Apr 28 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 09:11 PM, deadalnix wrote:
 Le 28/04/2012 20:47, Walter Bright a écrit :
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

I think many D features come from the lack of AOP in D. I already mentioned that in some other thread.

Many times, actually. But you have *never* sketched how support for AOP would look like.
 I would also mention the is expression which does way too many stuffs
 and many of them are not usefull or counter intuitive and may be
 replaced by lib support in std.traits .

Apr 28 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 28/04/2012 22:25, Timon Gehr a écrit :
 On 04/28/2012 09:11 PM, deadalnix wrote:
 Le 28/04/2012 20:47, Walter Bright a écrit :
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

I think many D features come from the lack of AOP in D. I already mentioned that in some other thread.

Many times, actually. But you have *never* sketched how support for AOP would look like.

Off topic. I discussed several proposals, and I invest time ever since to come up with a good solution. Introducing a whole new paradigm in a language isn't something light. AST manipulation at compile time is the key.
Apr 28 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-29 00:02, deadalnix wrote:

 Off topic. I discussed several proposals, and I invest time ever since
 to come up with a good solution. Introducing a whole new paradigm in a
 language isn't something light.

 AST manipulation at compile time is the key.

This would be awesome to have. -- /Jacob Carlborg
Apr 29 2012
prev sibling next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jnhe1i$2vcm$1 digitalmars.com...
 Andrei and I had a fun discussion last night about this question. The idea 
 was which features in D are redundant and/or do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble and 
 creal types.

 What's your list?

Off the top of my head: - Using function stubs so the implementation can be provided in a separate source and linked in. (Outside of .di files anyway.) - Comma operator - Version blocks: They should be replaced with something that utilizes "static if".
Apr 28 2012
next sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 19:21:51 UTC, Nick Sabalausky wrote:
 "Walter Bright" <newshound2 digitalmars.com> wrote in message

 - Version blocks: They should be replaced with something that 
 utilizes
 "static if".

Version could be replaced with "static if", but I like them, it makes code more readable, so I don't think they should go. We don't want to have a "static if hell", where templating code is mixed with version configuration. I think the version keyword is very good. I think instead of thinking about removing features, the more important thing is polishing the existing ones so that they work properly. D is a big language because it tries to span a broad range of uses. Removing complexity from the core language often means adding complexity in the user code, and that's what we don't want.
Apr 28 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.04.2012 22:59, schrieb q66:
 On Saturday, 28 April 2012 at 20:35:40 UTC, SomeDude wrote:
 On Saturday, 28 April 2012 at 20:09:50 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 20:05:30 UTC, SomeDude wrote:

 There are minimalistic languages that don't add too much complexity,
 instead it results in code being kept simple.

I appreciate minimalistic languages. I love the simplicity of Scheme and the design of Lua. Lua and Python are extensible language, but truth be told, they cannot handle large scale programming. In fact, I don't know of any minimalistic language that can scale from hundreds of thousands to millions of lines of code. When you reach these sizes, their simple design becomes a drawback. You start missing lots of features. When you reach large scale programming, you want really powerful tools. That's basically what the Java designers discovered after experience. The original language was simple and easy, but that simplicity translated into way too much boilerplate code. So they kept adding features from version to version, generics, then annotations, a means to create new keywords. And now they would like to add delegates. These are all needed in large programs.
 D needs to do something it does really well and concentrate on that.
 Otherwise the language will remain being rather vague and doing "a
 bit of everything, but nothing truly well".

It does a lot of things well already. Our point of comparison should not be Python or Lua, it must be C, C++, C#, Haskell, Ocaml, i.e languages that are designed to develop large systems. But most of all it needs to stabilize and polish, not change all the time. I think its feature set is very good already. We are far from having explored all its possibilities.
 Instead of adding more and more features into a rigid language, it
 needs to be made more flexible and extensible, both syntactically and
 semantically.


This kind of attitude "we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap" is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project.

Python is my favorite scripting language, but I would never propose a dynamic language for programming on the large. My employer does consulting for big projects. The type of entreprise projects that require multi-site development scattered across the globe, sometimes with 300+ developers. There is no way a dynamic language would work in such scenarios, without having a constant broken build on the CI system. -- Paulo
Apr 28 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 29.04.2012 17:27, schrieb H. S. Teoh:
 On Sun, Apr 29, 2012 at 08:40:16AM +0200, Paulo Pinto wrote:
 [...]

 less than a day (probably less than an hour).

Suffice to say, that on that specific project we had weeks without any working build, that had to be saved with hard code free rules until it got green again. This type of projects is what made me change my mind about static vs dynamic. Static languages with automatic type inference, and some type of dynamic dispatch like D's variant type/opDispatch, fullfil most use cases a dynamic language is good for, without sacrificing tooling or large scale development. -- Paulo
Apr 29 2012
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 08:40, Paulo Pinto wrote:
 Am 28.04.2012 22:59, schrieb q66:
 On Saturday, 28 April 2012 at 20:35:40 UTC, SomeDude wrote:
 On Saturday, 28 April 2012 at 20:09:50 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 20:05:30 UTC, SomeDude wrote:

 There are minimalistic languages that don't add too much complexity,
 instead it results in code being kept simple.

I appreciate minimalistic languages. I love the simplicity of Scheme and the design of Lua. Lua and Python are extensible language, but truth be told, they cannot handle large scale programming. In fact, I don't know of any minimalistic language that can scale from hundreds of thousands to millions of lines of code. When you reach these sizes, their simple design becomes a drawback. You start missing lots of features. When you reach large scale programming, you want really powerful tools. That's basically what the Java designers discovered after experience. The original language was simple and easy, but that simplicity translated into way too much boilerplate code. So they kept adding features from version to version, generics, then annotations, a means to create new keywords. And now they would like to add delegates. These are all needed in large programs.
 D needs to do something it does really well and concentrate on that.
 Otherwise the language will remain being rather vague and doing "a
 bit of everything, but nothing truly well".

It does a lot of things well already. Our point of comparison should not be Python or Lua, it must be C, C++, C#, Haskell, Ocaml, i.e languages that are designed to develop large systems. But most of all it needs to stabilize and polish, not change all the time. I think its feature set is very good already. We are far from having explored all its possibilities.
 Instead of adding more and more features into a rigid language, it
 needs to be made more flexible and extensible, both syntactically and
 semantically.


This kind of attitude "we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap" is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project.

Python is my favorite scripting language, but I would never propose a dynamic language for programming on the large. My employer does consulting for big projects. The type of entreprise projects that require multi-site development scattered across the globe, sometimes with 300+ developers. There is no way a dynamic language would work in such scenarios, without having a constant broken build on the CI system. -- Paulo

Wait, dynamic-language programmers use CI? *ducks and runs* -- - Alex
Apr 29 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Saturday, 28 April 2012 at 20:05:30 UTC, SomeDude wrote:
 On Saturday, 28 April 2012 at 19:21:51 UTC, Nick Sabalausky 
 wrote:
 "Walter Bright" <newshound2 digitalmars.com> wrote in message

 - Version blocks: They should be replaced with something that 
 utilizes
 "static if".

Version could be replaced with "static if", but I like them, it makes code more readable, so I don't think they should go. We don't want to have a "static if hell", where templating code is mixed with version configuration. I think the version keyword is very good. I think instead of thinking about removing features, the more important thing is polishing the existing ones so that they work properly. D is a big language because it tries to span a broad range of uses. Removing complexity from the core language often means adding complexity in the user code, and that's what we don't want.

There are minimalistic languages that don't add too much complexity, instead it results in code being kept simple. D needs to do something it does really well and concentrate on that. Otherwise the language will remain being rather vague and doing "a bit of everything, but nothing truly well". Instead of adding more and more features into a rigid language, it needs to be made more flexible and extensible, both syntactically and semantically.
Apr 28 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 20:09:50 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 20:05:30 UTC, SomeDude wrote:

 There are minimalistic languages that don't add too much 
 complexity, instead it results in code being kept simple.

I appreciate minimalistic languages. I love the simplicity of Scheme and the design of Lua. Lua and Python are extensible language, but truth be told, they cannot handle large scale programming. In fact, I don't know of any minimalistic language that can scale from hundreds of thousands to millions of lines of code. When you reach these sizes, their simple design becomes a drawback. You start missing lots of features. When you reach large scale programming, you want really powerful tools. That's basically what the Java designers discovered after experience. The original language was simple and easy, but that simplicity translated into way too much boilerplate code. So they kept adding features from version to version, generics, then annotations, a means to create new keywords. And now they would like to add delegates. These are all needed in large programs.
 D needs to do something it does really well and concentrate on 
 that. Otherwise the language will remain being rather vague and 
 doing "a bit of everything, but nothing truly well".

It does a lot of things well already. Our point of comparison should not be Python or Lua, it must be C, C++, C#, Haskell, Ocaml, i.e languages that are designed to develop large systems. But most of all it needs to stabilize and polish, not change all the time. I think its feature set is very good already. We are far from having explored all its possibilities.
 Instead of adding more and more features into a rigid language, 
 it needs to be made more flexible and extensible, both 
 syntactically and semantically.

Apr 28 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Saturday, 28 April 2012 at 20:35:40 UTC, SomeDude wrote:
 On Saturday, 28 April 2012 at 20:09:50 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 20:05:30 UTC, SomeDude wrote:

 There are minimalistic languages that don't add too much 
 complexity, instead it results in code being kept simple.

I appreciate minimalistic languages. I love the simplicity of Scheme and the design of Lua. Lua and Python are extensible language, but truth be told, they cannot handle large scale programming. In fact, I don't know of any minimalistic language that can scale from hundreds of thousands to millions of lines of code. When you reach these sizes, their simple design becomes a drawback. You start missing lots of features. When you reach large scale programming, you want really powerful tools. That's basically what the Java designers discovered after experience. The original language was simple and easy, but that simplicity translated into way too much boilerplate code. So they kept adding features from version to version, generics, then annotations, a means to create new keywords. And now they would like to add delegates. These are all needed in large programs.
 D needs to do something it does really well and concentrate on 
 that. Otherwise the language will remain being rather vague 
 and doing "a bit of everything, but nothing truly well".

It does a lot of things well already. Our point of comparison should not be Python or Lua, it must be C, C++, C#, Haskell, Ocaml, i.e languages that are designed to develop large systems. But most of all it needs to stabilize and polish, not change all the time. I think its feature set is very good already. We are far from having explored all its possibilities.
 Instead of adding more and more features into a rigid 
 language, it needs to be made more flexible and extensible, 
 both syntactically and semantically.


This kind of attitude "we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap" is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project.
Apr 28 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote:
 This kind of attitude "we need big fat bullshit like Java and 
 heavy use of OO and idioms and EH and all that other crap" is 
 broken and false. And you have no way to prove that Python for 
 example wouldn't scale for large projects; its main fault is 
 that the default implementation is rather slow, but it's not 
 pretty much missing anything required for a large project.

Python has two big drawbacks for large projects: - it's too slow - it's a dynamically-typed language The fact that it's flexible is because it uses duck typing, and AFAIK you can't do duck typing in a statically typed language. So it's cool for small programs, but it can't handle large ones because it's not statically typed. And this opinion doesn't come just out of thin air, I speak from my own professional experience.
Apr 28 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 20:35:40 UTC, SomeDude wrote:

 This kind of attitude "we need big fat bullshit like Java and 
 heavy use of OO and idioms and EH and all that other crap" is 
 broken and false. And you have no way to prove that Python for 
 example wouldn't scale for large projects; its main fault is 
 that the default implementation is rather slow, but it's not 
 pretty much missing anything required for a large project.

BTW, look at Scala for another language that's designed for large scale programming (as its name implies). Scala is a very good design, some even think it's the Java killer. But I think it's even more complex than D.
Apr 28 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 11:12:38PM +0200, SomeDude wrote:
 On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote:
This kind of attitude "we need big fat bullshit like Java and
heavy use of OO and idioms and EH and all that other crap" is
broken and false. And you have no way to prove that Python for
example wouldn't scale for large projects; its main fault is that
the default implementation is rather slow, but it's not pretty
much missing anything required for a large project.

Python has two big drawbacks for large projects: - it's too slow - it's a dynamically-typed language The fact that it's flexible is because it uses duck typing, and AFAIK you can't do duck typing in a statically typed language. So it's cool for small programs, but it can't handle large ones because it's not statically typed. And this opinion doesn't come just out of thin air, I speak from my own professional experience.

Who says D doesn't have duck-typing? template isADuck(T) { alias isADuck = is(typeof(T.quack())==bool); } void petADuck(T)(T duck) if (isADuck!T) { duck.quack(); } You can pass anything that has a quack() method to the function: struct CanadianDuck { void quack() { writeln("Quack, eh?"); } } class AmericanDuck { void quack() { writeln("Quack, yo!"); } } struct RubberDuck { void opDispatch!(string S)() { auto d = loadRuntimeDuckClass(); d.callMethod(S); } } struct Cow { void moo() { writeln("Mooo!"); } } void main() { CanadianDuck caddie; AmericanDuck quacker = new AmericanDuck; RubberDuck runtimeDuck; Cow orker; // Look, ma! I hez duck-taiping! petADuck(caddie); petADuck(quacker); petADuck(runtimeDuck); // Reject non-duck objects petADuck(orker); // compile error: orker is not a duck! } Not only D supports duck-typing, the compiler even checks type-safety for you at compile-time. ;-) Incidentally, this is what the Phobos range interface does. T -- My program has no bugs! Only undocumented features...
Apr 28 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.67.1335651468.24740.digitalmars-d puremagic.com...
 On Sat, Apr 28, 2012 at 11:12:38PM +0200, SomeDude wrote:
 On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote:
This kind of attitude "we need big fat bullshit like Java and
heavy use of OO and idioms and EH and all that other crap" is
broken and false. And you have no way to prove that Python for
example wouldn't scale for large projects; its main fault is that
the default implementation is rather slow, but it's not pretty
much missing anything required for a large project.

Python has two big drawbacks for large projects: - it's too slow - it's a dynamically-typed language The fact that it's flexible is because it uses duck typing, and AFAIK you can't do duck typing in a statically typed language. So it's cool for small programs, but it can't handle large ones because it's not statically typed. And this opinion doesn't come just out of thin air, I speak from my own professional experience.

Who says D doesn't have duck-typing?

Yea, templated code is structurally-typed (duck-typed) by default. Not a big fan of that personally, but I can live with it, and D is awesome enough that you can build nominal-typing out of it: http://www.semitwist.com/articles/EfficientAndFlexible/MultiplePages/Page5/
Apr 28 2012
prev sibling next sibling parent "Jonas Drewsen" <jdrewsen nospam.com> writes:
On Saturday, 28 April 2012 at 21:12:39 UTC, SomeDude wrote:
 On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote:
 This kind of attitude "we need big fat bullshit like Java and 
 heavy use of OO and idioms and EH and all that other crap" is 
 broken and false. And you have no way to prove that Python for 
 example wouldn't scale for large projects; its main fault is 
 that the default implementation is rather slow, but it's not 
 pretty much missing anything required for a large project.

Python has two big drawbacks for large projects: - it's too slow - it's a dynamically-typed language The fact that it's flexible is because it uses duck typing, and AFAIK you can't do duck typing in a statically typed language. So it's cool for small programs, but it can't handle large ones because it's not statically typed. And this opinion doesn't come just out of thin air, I speak from my own professional experience.

Go is a static duck typed language (when using interfaces anyway) AFAIK. http://golang.org/doc/go_faq.html#implements_interface http://research.swtch.com/interfaces /Jonas
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 28 April 2012 at 21:12:39 UTC, SomeDude wrote:
 […] And this opinion doesn't come just out of thin air, I 
 speak from my own professional experience.

Regardless of the fact that I tend to agree with you on this one, isn't »my own professional experience« usually a synonym for »thin air«? ;) David
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 08:40:16AM +0200, Paulo Pinto wrote:
[...]
 My employer does consulting for big projects. The type of entreprise
 projects that require multi-site development scattered across the
 globe, sometimes with 300+ developers.
 
 There is no way a dynamic language would work in such scenarios,
 without having a constant broken build on the CI system.

Yeah, at my work we have about 20-30 people working on a very large C/C++ codebase (one among many), and we already get broken builds every now and then, like bugs that completely break just about every feature in the system -- makes you wonder how any sane programmer could've checked in such a mess (and how said mess made it through the kangaroo code review process). Or blatant internal API breakages that make you wonder if anybody even *read* what they wrote. I cannot begin to imagine the horror of using a dynamic language in this setting. Static languages are already painful enough; throw in indeterminate typing at compile-time and it's a recipe for utter disaster, probably every single work day. And this is only 20-30 developers. The problem gets exponentially worse when that number goes up. At 300+ developers, the project would grind to a complete halt in less than a day (probably less than an hour). T -- Study gravitation, it's a field with a lot of potential.
Apr 29 2012
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 09:52:21 UTC, David Nadlinger wrote:
 On Saturday, 28 April 2012 at 21:12:39 UTC, SomeDude wrote:
 […] And this opinion doesn't come just out of thin air, I 
 speak from my own professional experience.

Regardless of the fact that I tend to agree with you on this one, isn't »my own professional experience« usually a synonym for »thin air«? ;) David

Well yes and no. It's the difference between "I think that", and "I've experienced in real projects that". And well, discussing in another forum, I've had other similar echos and experiences. Basically, with Python and other dynamically typed languages, the time you gain writing code, you lose testing it and correcting bugs that a compiler would have found for you.
Apr 29 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 28.04.2012 22:47, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

1. Drop is(...) feature entirely. Extend __traits where needed and move compile-time reflection to "magic" meta namespace completely. 2. "enum as manifest constant". Use static or immutable/global. Compiler should be smart enough to avoid putting immutable integers/doubles into object file as variables. 3. with statement (?). I kind of like it but bleh it's too boggy and it doesn't seem to pull its weight. (pointers? class references? a lot of stuff to go wrong) Fluent interfaces solve a good portion of its benefits to be specific. 4. foreach_reverse. Seriously let's kill this abomination. If it happens that foreach(x; retro(range)){...} is slower it just means compiler (inlining?) is no good and should be improved. 5. .tupleof looks like a hack. But I'd rather "refactor" than drop it. 6. Drop out arguments? There are tuples. And auto (a, b) = getMeTwoThings(); is cleanerthan <something> a, b; fillTheseTwoThings(a, b); // no indication whatsoever that a & b are modified heck even fn(&a, &b) in C is *better* (ok no tuple unpacking for now but you got the idea) 7. I can live without homogenous varaidics. Since most of the time they readily progress to full-blown variadics that detect common type & forward things to an array version of function. Also given that sometimes people do things like: this(int[] arr...)// ctor with cool syntax, yada-yada ;) { this.data = arr; //boom! (pointer to stack-allocated stuff) } 8. Something else. D is huge :) -- Dmitry Olshansky
Apr 28 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 09:22 PM, Dmitry Olshansky wrote:
 On 28.04.2012 22:47, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

1. Drop is(...) feature entirely. Extend __traits where needed and move compile-time reflection to "magic" meta namespace completely. 2. "enum as manifest constant". Use static or immutable/global.

static is not accessible at compile time, would you want to change that? immutable is not an option because it infects the type. Furthermore, I like 'enum' because it is concise. What is the issue with enum?
 Compiler should be smart enough

Smart compiler fallacy. It really cannot be that smart in this case.
 to avoid putting immutable integers/doubles into
 object file as variables.

Their address might be taken by code that is unavailable! Furthermore, many of my enums are strings or arrays.
 8. Something else. D is huge :)

I actually think D is not too large.
Apr 28 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29.04.2012 0:57, Timon Gehr wrote:
 On 04/28/2012 09:22 PM, Dmitry Olshansky wrote:
 On 28.04.2012 22:47, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

1. Drop is(...) feature entirely. Extend __traits where needed and move compile-time reflection to "magic" meta namespace completely. 2. "enum as manifest constant". Use static or immutable/global.

static is not accessible at compile time, would you want to change that? immutable is not an option because it infects the type.

But how about: alias thing = runSomeCtfe(); And bring the usual alias to new_name = <something>; form (even C++ finally got this right with C++11 aliases).
 Furthermore, I like 'enum' because it is concise.

 What is the issue with enum?

 Compiler should be smart enough

Smart compiler fallacy. It really cannot be that smart in this case.
 to avoid putting immutable integers/doubles into
 object file as variables.

Their address might be taken by code that is unavailable! Furthermore, many of my enums are strings or arrays.
 8. Something else. D is huge :)

I actually think D is not too large.

For what it does - surely not. But in general it's big. For one it's not smaller then C++. 8. synchronized. scope(exit) mutex.unlock(); is fine in cases where RAII is awkward. -- Dmitry Olshansky
Apr 28 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 11:04 PM, Dmitry Olshansky wrote:
 On 29.04.2012 0:57, Timon Gehr wrote:
 On 04/28/2012 09:22 PM, Dmitry Olshansky wrote:
 On 28.04.2012 22:47, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add
 significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

1. Drop is(...) feature entirely. Extend __traits where needed and move compile-time reflection to "magic" meta namespace completely. 2. "enum as manifest constant". Use static or immutable/global.

static is not accessible at compile time, would you want to change that? immutable is not an option because it infects the type.

But how about: alias thing = runSomeCtfe();

That would work in certain cases, where the initializer is not a single symbol. But then, I kinda like the way 'enum' is generalized in D: enum Foo{ member1, member2, member3, } => (allow non-integral enumerations) enum Foo{ member1 = "1", member2 = "2", member3 = "3", } => (anonymous enums) enum{ member1 = "1", member2 = "2", member3 = "3", } => (a single member is okay) enum{ member1 = "1", } => (syntactic sugar) enum member1 = "1";
 And bring the usual alias to new_name = <something>;
 form (even C++ finally got this right with C++11 aliases).

This is probably something that should be done.
 I actually think D is not too large.

For what it does - surely not. But in general it's big. For one it's not smaller then C++.

I am not sure how to compare, but D 'feels' smaller than C++ to me. Implementing a compiler is probably harder for D, because of the interplay of forward references, CTFE and compile time introspection.
Apr 28 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:jnhpvv$ih4$1 digitalmars.com...
 On 04/28/2012 11:04 PM, Dmitry Olshansky wrote:
 But how about:
 alias thing = runSomeCtfe();

That would work in certain cases, where the initializer is not a single symbol. But then, I kinda like the way 'enum' is generalized in D: enum Foo{ member1, member2, member3, } => (allow non-integral enumerations) enum Foo{ member1 = "1", member2 = "2", member3 = "3", }

Those are good. They are essentially enumerations.
 => (anonymous enums)

 enum{
     member1 = "1",
     member2 = "2",
     member3 = "3",
 }

I don't think "anonymous enum" makes any sense at all. It's *not* an enumeration by any stretch of the term, it's just a series of manifest constants. The fact that they're grouped doesn't even have any semantic consequence, as far as I'm aware.
 => (a single member is okay)

 enum{
     member1 = "1",
 }

 => (syntactic sugar)

 enum member1 = "1";

Just simpler examples of the above, which isn't any form of enumeration at all.
 And bring the usual alias to new_name = <something>;
 form (even C++ finally got this right with C++11 aliases).

This is probably something that should be done.

Emphatic +1 I always have to stop and think carefully about the order when I write an alias.
 Implementing a compiler is probably harder for D, because of the interplay 
 of forward references, CTFE and compile time introspection.

Those make D more difficult to implement than many languages, but OTOH, AIUI, C++ has some real nightmarish details with templates and even just simply parsing. Probably some other bizarre cruft, too. IIRC, I think Walter's occasionally mentioned something about the...overload rules?
Apr 28 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 08:35 AM, Nick Sabalausky wrote:
 "Timon Gehr"<timon.gehr gmx.ch>  wrote in message
 news:jnhpvv$ih4$1 digitalmars.com...
 On 04/28/2012 11:04 PM, Dmitry Olshansky wrote:
 But how about:
 alias thing = runSomeCtfe();

That would work in certain cases, where the initializer is not a single symbol. But then, I kinda like the way 'enum' is generalized in D: enum Foo{ member1, member2, member3, } => (allow non-integral enumerations) enum Foo{ member1 = "1", member2 = "2", member3 = "3", }

Those are good. They are essentially enumerations.
 =>  (anonymous enums)

 enum{
      member1 = "1",
      member2 = "2",
      member3 = "3",
 }

I don't think "anonymous enum" makes any sense at all. It's *not* an enumeration by any stretch of the term,

enum{ member1, member2, member3, } static assert(member1+1==member2 && member2+1==member3);
 it's just a series of manifest
 constants. The fact that they're grouped doesn't even have any semantic
 consequence, as far as I'm aware.

The only differences are that they don't occupy their own namespace and they don't define their own type. But non-anonymous enums are _just a bunch of manifest constants_ as well! Therefore there are ways in which the generalisation makes sense.
 =>  (a single member is okay)

 enum{
      member1 = "1",
 }

 =>  (syntactic sugar)

 enum member1 = "1";

Just simpler examples of the above, which isn't any form of enumeration at all.

'enum' declares manifest constants whether or not it is anonymous. Afaik go uses 'const' for enumerations and manifest constants. 'const' means a different thing in D. (arguably, 'readonly' would be a better fit) I don't think that the exact keywords matter a huge deal here.
Apr 29 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:jnj92m$306m$1 digitalmars.com...
 On 04/29/2012 08:35 AM, Nick Sabalausky wrote:

 it's just a series of manifest
 constants. The fact that they're grouped doesn't even have any semantic
 consequence, as far as I'm aware.

The only differences are that they don't occupy their own namespace and they don't define their own type. But non-anonymous enums are _just a bunch of manifest constants_ as well!

No, they're not. Non-anon enums *contain* a bunch of manifest constants. But what non-anon enums *are* is a type. Anon enums are not a type at all. I think that's a significant difference. Note this is in stark contrast to: - Classes: Anonymous or not, it's still a type. - Functions: Anonymous or not, it's still *not* a type. The syntaxes we have for anon enums and non-anon enums makes them *look* like they're basically the same thing, just with/without a name, but that's not actually the case. Of course, my biggest issue by far is with the name "enum". Non-anon enums can reasonably be thought of as enumerations (except for bitfields, but I think those should be handled differently from enums anyway). But anon-enums are just plain not enumerations, period. If we weren't calling them all "enum", then I would have much, much less problem with the syntax we have. And yea, I get the whole "What's in a name?", but "enum" is just a colossally *terrible* name for this. It's worse than when "immutable" was called "invariant".
Apr 29 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 04/29/2012 12:12 PM, Nick Sabalausky wrote:
 "Timon Gehr"<timon.gehr gmx.ch>  wrote in message
 news:jnj92m$306m$1 digitalmars.com...
 On 04/29/2012 08:35 AM, Nick Sabalausky wrote:

 it's just a series of manifest
 constants. The fact that they're grouped doesn't even have any semantic
 consequence, as far as I'm aware.

The only differences are that they don't occupy their own namespace and they don't define their own type. But non-anonymous enums are _just a bunch of manifest constants_ as well!

No, they're not. Non-anon enums *contain* a bunch of manifest

 what non-anon enums *are* is a type. Anon enums are not a type at all. I
 think that's a significant difference.

I see that way as well. I have a section titled "enum values that are not of an enum type" at http://ddili.org/ders/d.en/enum.html: [quote] sometimes it may not be natural to come up with enum type names just to use named constants. Let's assume that a named constant is needed to represent the number of seconds per day. It should not be necessary to also define an enum type for this constant value. All that is needed is a constant value that can be referred to by its name. In such cases, the type of the enum and the value parentheses are not specified: enum secondsPerDay = 60 * 60 * 24; [/quote]
 Of course, my biggest issue by far is with the name "enum".

Agreed. It became a bad name as soon as any value other than a number could be an enum value (or "member").
 Non-anon enums
 can reasonably be thought of as enumerations (except for bitfields, but I
 think those should be handled differently from enums anyway). But 

 are just plain not enumerations, period. If we weren't calling them all
 "enum", then I would have much, much less problem with the syntax we 

 And yea, I get the whole "What's in a name?", but "enum" is just a
 colossally *terrible* name for this. It's worse than when "immutable" was
 called "invariant".

Ali
Apr 30 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 05:17 PM, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 02:35:07AM -0400, Nick Sabalausky wrote:
 "Timon Gehr"<timon.gehr gmx.ch>  wrote in message
 news:jnhpvv$ih4$1 digitalmars.com...

 Implementing a compiler is probably harder for D, because of the
 interplay of forward references, CTFE and compile time
 introspection.

Those make D more difficult to implement than many languages, but OTOH, AIUI, C++ has some real nightmarish details with templates and even just simply parsing. Probably some other bizarre cruft, too. IIRC, I think Walter's occasionally mentioned something about the...overload rules?


C++ implementation complexity is incidental.
 It has been said that C++ cannot be lexed before it's parsed.  Before
 C++11, for example, this is invalid:

 	std::vector<std::vector<T>>  nestedList;

 Instead, you have to write:

 	std::vector<std::vector<T>  >  nestedList;

 Fortunately they fixed this in C++11. But now you have another problem:

 	std::vector<myTemplate<T>>1>  nestedList;

 Whether or not this is valid depends on whether T is a type name or a
 variable name

I think it is never valid.
 (e.g., if myTemplate takes an int parameter). But how is
 the lexer even supposed to know whether the>>  should be a right shift
 operator or two right angle brackets? It has to understand the
 _semantics_ of T before it can even lex the thing.

A D compiler has to semantically analyse the code without full information about which symbols are declared, (getting the full set of declared symbols is actually an ill-defined problem because conditional compilation is Turing complete and can already depend on any declared symbol or even on the fact that a certain symbol has _not_ been declared). There might also be ambiguities or contradictions in the code that a compiler should detect. There is no mention of this issue or its (necessarily conservative and somewhat arbitrary) solution in the language documentation. DMD does not solve the problem, but just fails in funny ways when faced with a non-trivial instance of it. C++ does not have such issues at all because it disallows forward references! Don't get me wrong, I think this is rather awesome. But I predict it will be somewhat of a roadblock for getting the language into a stable state.
 I read somewhere that one of D's goals was to be able to lex the
 language without requiring semantic knowledge in the lexer.

This is required in order to have forward references.
 You have no idea

I do.
 how much such a seemingly-obvious concept can save hours, days,
 nay, months and years of frustration in compiler implementation.

 So you think D is hard to implement? We have barely even begun to delve
 into the insane convolutions of C++. You'll start to have some real
 hair-tearing sessions once you start getting into implicit conversion
 rules

Well, again, DMD does not get those right. And there is some black magic in that area, because the implicitly-converts-to-relation is from expressions to types instead of from types to types. (which is awesome of course, but it is complex to get right). Try this (this *should* compile). pragma(msg, typeof(1?[[]]:[[1]])); pragma(msg, typeof(1?1?[[]]:[[]]:[[1]])); pragma(msg, typeof([[[]],[[]],[[1]]])); class C{} static C[] c = [null]; pragma(msg, typeof([[null],[new C]]));
 and template best-match algorithms. Be glad, be very glad that we
 have D instead of C++!

static if(!is(typeof(foo))) enum bar = 1; static if(!is(typeof(bar))) enum foo = 1; In D, most of the complexity stems from its advanced features, while in C++ a lot of the complexity is merely incidental.
Apr 29 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
 2. "enum as manifest constant". Use static or immutable/global. 
 Compiler should be smart enough to avoid putting immutable 
 integers/doubles into object file as variables.

But enums aren't only used for optimization. What if you want to use a constant at compile time, as a template parameter?
Apr 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 02:35:07AM -0400, Nick Sabalausky wrote:
 "Timon Gehr" <timon.gehr gmx.ch> wrote in message 
 news:jnhpvv$ih4$1 digitalmars.com...

 Implementing a compiler is probably harder for D, because of the
 interplay of forward references, CTFE and compile time
 introspection.

Those make D more difficult to implement than many languages, but OTOH, AIUI, C++ has some real nightmarish details with templates and even just simply parsing. Probably some other bizarre cruft, too. IIRC, I think Walter's occasionally mentioned something about the...overload rules?

It has been said that C++ cannot be lexed before it's parsed. Before C++11, for example, this is invalid: std::vector<std::vector<T>> nestedList; Instead, you have to write: std::vector<std::vector<T> > nestedList; Fortunately they fixed this in C++11. But now you have another problem: std::vector<myTemplate<T>>1> nestedList; Whether or not this is valid depends on whether T is a type name or a variable name (e.g., if myTemplate takes an int parameter). But how is the lexer even supposed to know whether the >> should be a right shift operator or two right angle brackets? It has to understand the _semantics_ of T before it can even lex the thing. I read somewhere that one of D's goals was to be able to lex the language without requiring semantic knowledge in the lexer. You have no idea how much such a seemingly-obvious concept can save hours, days, nay, months and years of frustration in compiler implementation. So you think D is hard to implement? We have barely even begun to delve into the insane convolutions of C++. You'll start to have some real hair-tearing sessions once you start getting into implicit conversion rules and template best-match algorithms. Be glad, be very glad that we have D instead of C++! T -- Designer clothes: how to cover less by paying more.
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 15:16:57 UTC, H. S. Teoh wrote:
 […] and template best-match algorithms. Be glad, be very glad 
 that we have D instead of C++!

To be fair, the template matching logic in D is quite complicated as well (at least I can recall several instances of stumbling over bugs in the implementation, would have to search Bugzilla for details) – the only thing is that we don't really have a formal spec for it yet… David
Apr 29 2012
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 28/04/2012 20:22, Dmitry Olshansky wrote:
 3. with statement (?). I kind of like it but bleh it's too boggy and it
 doesn't seem to pull its weight. (pointers? class references? a lot of
 stuff to go wrong) Fluent interfaces solve a good portion of its
 benefits to be specific.

My primary use case for the with() statement is with final switch: final switch(something) with(MyEnumWithAPrettyLongName) { case A: // Save repeating myself everywhere break; . . . } -- Robert http://octarineparrot.com/
Apr 29 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 30-04-2012 02:40, Robert Clipsham wrote:
 On 28/04/2012 20:22, Dmitry Olshansky wrote:
 3. with statement (?). I kind of like it but bleh it's too boggy and it
 doesn't seem to pull its weight. (pointers? class references? a lot of
 stuff to go wrong) Fluent interfaces solve a good portion of its
 benefits to be specific.

My primary use case for the with() statement is with final switch: final switch(something) with(MyEnumWithAPrettyLongName) { case A: // Save repeating myself everywhere break; . . . }

Hah, clever! Never would've thought of that. -- - Alex
Apr 29 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-30 02:40, Robert Clipsham wrote:
 On 28/04/2012 20:22, Dmitry Olshansky wrote:
 3. with statement (?). I kind of like it but bleh it's too boggy and it
 doesn't seem to pull its weight. (pointers? class references? a lot of
 stuff to go wrong) Fluent interfaces solve a good portion of its
 benefits to be specific.

My primary use case for the with() statement is with final switch: final switch(something) with(MyEnumWithAPrettyLongName) { case A: // Save repeating myself everywhere break; . . . }

That's the only thing I used the with-statement for. -- /Jacob Carlborg
Apr 30 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-30 12:29, Manu wrote:
 On 30 April 2012 10:39, Jacob Carlborg <doob me.com
     That's the only thing I used the with-statement for.


 That's the only thing I was aware it did ;) .. are there other uses?

You can use it to access members without a receiver as well: class Foo { int x; int y; } auto foo = new Foo; with (foo) { x = 3; y = 4; } http://dlang.org/statement.html#WithStatement -- /Jacob Carlborg
Apr 30 2012
prev sibling next sibling parent simendsjo <simendsjo gmail.com> writes:
On Mon, 30 Apr 2012 09:39:15 +0200, Jacob Carlborg <doob me.com> wrote:

 On 2012-04-30 02:40, Robert Clipsham wrote:
 On 28/04/2012 20:22, Dmitry Olshansky wrote:
 3. with statement (?). I kind of like it but bleh it's too boggy and it
 doesn't seem to pull its weight. (pointers? class references? a lot of
 stuff to go wrong) Fluent interfaces solve a good portion of its
 benefits to be specific.

My primary use case for the with() statement is with final switch: final switch(something) with(MyEnumWithAPrettyLongName) { case A: // Save repeating myself everywhere break; . . . }

That's the only thing I used the with-statement for.

I use it to "fake" object initializers from C#: http://msdn.microsoft.com/en-us/library/bb384062.aspx A feature I love in C# and would like to see in D.
Apr 30 2012
prev sibling next sibling parent "John Chapman" <johnch_atms hotmail.com> writes:
On Monday, 30 April 2012 at 07:49:48 UTC, simendsjo wrote:
 I use it to "fake" object initializers from C#: 
 http://msdn.microsoft.com/en-us/library/bb384062.aspx
 A feature I love in C# and would like to see in D.

Ooh, nice - care to share?
Apr 30 2012
prev sibling next sibling parent simendsjo <simendsjo gmail.com> writes:
On Mon, 30 Apr 2012 11:31:49 +0200, John Chapman <johnch_atms hotmail.com>  
wrote:

 On Monday, 30 April 2012 at 07:49:48 UTC, simendsjo wrote:
 I use it to "fake" object initializers from C#:  
 http://msdn.microsoft.com/en-us/library/bb384062.aspx
 A feature I love in C# and would like to see in D.

Ooh, nice - care to share?

Basically just auto c = new C; with(c) { field = value; }
Apr 30 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
--20cf30334cab7bcf9a04bee2ed89
Content-Type: text/plain; charset=UTF-8

On 30 April 2012 10:39, Jacob Carlborg <doob me.com> wrote:

 On 2012-04-30 02:40, Robert Clipsham wrote:

 On 28/04/2012 20:22, Dmitry Olshansky wrote:

 3. with statement (?). I kind of like it but bleh it's too boggy and it
 doesn't seem to pull its weight. (pointers? class references? a lot of
 stuff to go wrong) Fluent interfaces solve a good portion of its
 benefits to be specific.

My primary use case for the with() statement is with final switch: final switch(something) with(**MyEnumWithAPrettyLongName) { case A: // Save repeating myself everywhere break; . . . }


That's the only thing I was aware it did ;) .. are there other uses? --20cf30334cab7bcf9a04bee2ed89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 30 April 2012 10:3= 9, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"mailto:doob me.com" targ= et=3D"_blank">doob me.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> On 2012-04-30 02:40, Robert Clipsham wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 28/04/2012 20:22, Dmitry Olshansky wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> 3. with statement (?). I kind of like it but bleh it&#39;s too boggy and it= <br> doesn&#39;t seem to pull its weight. (pointers? class references? a lot of<= br> stuff to go wrong) Fluent interfaces solve a good portion of its<br> benefits to be specific.<br> </blockquote> <br> My primary use case for the with() statement is with final switch:<br> <br> final switch(something) with(<u></u>MyEnumWithAPrettyLongName)<br> {<br> case A: // Save repeating myself everywhere<br> break;<br> <br> . . .<br> <br> }<br> <br> </blockquote> <br> That&#39;s the only thing I used the with-statement for.</blockquote><div><= br></div><div>That&#39;s the only thing I was aware it did ;) .. are there = other uses?</div></div></div> --20cf30334cab7bcf9a04bee2ed89--
Apr 30 2012
prev sibling next sibling parent reply "q66" <quaker66 gmail.com> writes:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was which features in D are redundant and/or 
 do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble and creal types.

 What's your list?

- AAs integrated in the language; you barely ever use AA literals and having them purely in Phobos would help get rid of the runtime fat, as well as better implementations - Phobos is too fat - it needs to shrink to just a few core modules, others being distributed via some system like CPAN for Perl - Properties - they're kinda broken at this point and the value is questionable - trusted system - Exception handling - a lot of runtime, questionable value - Versions - not redundant, but needs a better system (with AND/OR, possibility of de-versioning, the assignment op to set versions is kinda bad) I think I would find some more, but these are the ones I can recall now.
Apr 28 2012
next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"q66" <quaker66 gmail.com> wrote in message 
news:ihqjguujvoukhlqcwkyi forum.dlang.org...
 - Phobos is too fat - it needs to shrink to just a few core modules, 
 others being distributed via some system like CPAN for Perl
 - Properties - they're kinda broken at this point and the value is 
 questionable
 -  trusted  system
 - Exception handling - a lot of runtime, questionable value

That's just craziness!
Apr 28 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 09:39 PM, Nick Sabalausky wrote:
 "q66"<quaker66 gmail.com>  wrote in message
 news:ihqjguujvoukhlqcwkyi forum.dlang.org...
 - Phobos is too fat - it needs to shrink to just a few core modules,
 others being distributed via some system like CPAN for Perl
 - Properties - they're kinda broken at this point and the value is
 questionable
 -  trusted  system
 - Exception handling - a lot of runtime, questionable value

That's just craziness!

+1.
Apr 28 2012
prev sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"SomeDude" <lovelydear mailmetrash.com> wrote in message 
news:jrdmqmchgbibqmrwzwsk forum.dlang.org...
 On Sunday, 29 April 2012 at 05:54:10 UTC, Marco Leise wrote:
 Am Sat, 28 Apr 2012 15:39:49 -0400

 Madness even! AAs are soon mostly in the library and that's a good 
 trade-off;  trusted  system needs to be there as long as there is  safe; 
 exception handling - some people rely on it heavily. See it as the easy 
 way to error out of a function that doesn't normally return anything and 
 cascade up several calls, while being able to release resources in each.
 I don't know about Phobos. Some batteries included are nice and help the 
 popularity. When it comes to bindings to third party products with many 
 alternatives, like databases, I'd say one should cut it there definitly.
 I can agree on the rest.

I don't want AA to be removed from the core language. That would be a big step backward in my opinion. Core language AAs are entirely adequate for a lot of applications, and they make for so much cleaner and easier to read/write code than template notation.

There will still be sugar in the compiler so they appear to be builtins. When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that "behind the scenes" their implementation will move from DMD to Druntime.
Apr 29 2012
next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> wrote in message 
news:jnit81$29uh$1 digitalmars.com...
 "SomeDude" <lovelydear mailmetrash.com> wrote in message 
 news:jrdmqmchgbibqmrwzwsk forum.dlang.org...
 On Sunday, 29 April 2012 at 05:54:10 UTC, Marco Leise wrote:
 Am Sat, 28 Apr 2012 15:39:49 -0400

 Madness even! AAs are soon mostly in the library and that's a good 
 trade-off;  trusted  system needs to be there as long as there is  safe; 
 exception handling - some people rely on it heavily. See it as the easy 
 way to error out of a function that doesn't normally return anything and 
 cascade up several calls, while being able to release resources in each.
 I don't know about Phobos. Some batteries included are nice and help the 
 popularity. When it comes to bindings to third party products with many 
 alternatives, like databases, I'd say one should cut it there definitly.
 I can agree on the rest.

I don't want AA to be removed from the core language. That would be a big step backward in my opinion. Core language AAs are entirely adequate for a lot of applications, and they make for so much cleaner and easier to read/write code than template notation.

There will still be sugar in the compiler so they appear to be builtins. When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that "behind the scenes" their implementation will move from DMD to Druntime.

In fact, don't regular arrays already work like this?
Apr 29 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 10:28 AM, SomeDude wrote:
 On Sunday, 29 April 2012 at 08:13:53 UTC, Nick Sabalausky wrote:
 There will still be sugar in the compiler so they appear to be builtins.
 When the switch happens, I'm sure it'll be transparent - average users
 probably won't even notice. It's just that "behind the scenes" their
 implementation will move from DMD to Druntime.

Hmmm, sounds nice, but bolting the language with the standard library is very risky (and a rather bad idea imho). Unless there is a very lightweight minimalistic core for Phobos (something which I advocate), you bolt a heavyweight library to your language, and that's not good.

druntime is the library it will be moved into, not Phobos.
Apr 29 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 11:05 PM, q66 wrote:
 On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
 [...]
 - AAs integrated in the language; you barely ever use AA literals and
 having them purely in Phobos would help get rid of the runtime fat, as
 well as better implementations

On the contrary, AA's are a major reason I started programming in D. In this day and age, it's simply inexcusable to *not* have some kind of hash type available by default.

Besides AA literals, library can handle this JUST FINE.

That is why they should be a narrow wrapper around a library defined type.
 - Phobos is too fat - it needs to shrink to just a few core modules,
 others being distributed via some system like CPAN for Perl

Um... that's what a *library* is supposed to be: a large collection of useful stuff from which you can pick the few that you need right now.

Too large collection becomes too hard to manage. Separating it and distributing in style "you pay for what you use" is IMO the right approach.

This sounds reasonable.
 - Properties - they're kinda broken at this point and the value is
 questionable

What kind of properties are you referring to?

The property crap. It's broken. If anything, it needs something like in C#.

As I understand it, the 'agreed upon' design is that property int foo() { return x; } property void foo(int v) { x = v; } Would be completely equivalent to C#: int foo { set{ x = value; }; get{ return x; } } I think it is even perfectly fine to just allow function calls without parentheses, but I wouldn't mind seeing that feature gone.
 -  trusted  system

These are necessary.

They're far from necessary.

Why? Memory safety is generally considered to be important.
 - Exception handling - a lot of runtime, questionable value

I completely disagree. No exception handling means lots and lots and lots of boilerplate code for checking error codes, return values, which are too tedious to write, which translates to many people leaving them out and ending up with unreliable code that fail silently or crash outright when a function call they assumed would work stopped working. If you've worked in large multi-person projects, you'll see very quickly why you *need* exception handling. No modern language can do without exception handling. Maybe you have a beef with how it's currently done in D, but regardless, you *need* exception handling of some kind.

The exception handling system via try/catch is as bad and tedious as error codes, except the added runtime.

It can improve performance though, because the exceptional branches don't occur in the code that is normally executed.
 It all roots from the idea "catch everything that throws".
 This is broken, as you DON'T always need to
 handle all sorts of errors (letting it segfault or something sometimes
 simply proves to be better than trying to save the situation;

Except that it won't necessarily segfault. That is not how _reliable_ systems work. Robustness is an important property of critical systems. If your software might kill people if it behaves in the wrong way, you really really don't want to ignore error conditions.
 or you can simply assert it).

Certainly, if it is a consistency criterion internal to the program, then assertions should be used.
 Also http://yosefk.com/c++fqa/exceptions.html#fqa-17.1
 [snip.]

The part of this article relevant for D is this: "Still, in many cases, the benefits of exceptions are more important than their problems. For example, if your language manages memory automatically, the problem of releasing acquired resources becomes a small one (you only have to care about files, etc., which are a tiny part of the "resources" used by a program - most of the "resources" are memory). If your language throws exceptions when you violate its rules (for example, upon out-of-bounds array access), these exceptions will help you find lots of bugs, especially if you can get the call stack from an exception. If the purpose of an application is automated testing, and/or it's used as a quick-and-dirty internal tool as opposed to a product for an end user, this kind of exceptions is all you need to handle errors of almost all kinds. In some languages, you can even resume the execution from the point where the exception was raised after fixing the problem at the point where it was caught." Anyway, I generally avoid exceptions if they are not an obvious fit.
Apr 28 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 28-04-2012 23:41, Timon Gehr wrote:
 On 04/28/2012 11:05 PM, q66 wrote:
 On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
 [...]
 - AAs integrated in the language; you barely ever use AA literals and
 having them purely in Phobos would help get rid of the runtime fat, as
 well as better implementations

On the contrary, AA's are a major reason I started programming in D. In this day and age, it's simply inexcusable to *not* have some kind of hash type available by default.

Besides AA literals, library can handle this JUST FINE.

That is why they should be a narrow wrapper around a library defined type.
 - Phobos is too fat - it needs to shrink to just a few core modules,
 others being distributed via some system like CPAN for Perl

Um... that's what a *library* is supposed to be: a large collection of useful stuff from which you can pick the few that you need right now.

Too large collection becomes too hard to manage. Separating it and distributing in style "you pay for what you use" is IMO the right approach.

This sounds reasonable.
 - Properties - they're kinda broken at this point and the value is
 questionable

What kind of properties are you referring to?

The property crap. It's broken. If anything, it needs something like in C#.

As I understand it, the 'agreed upon' design is that property int foo() { return x; } property void foo(int v) { x = v; } Would be completely equivalent to C#: int foo { set{ x = value; }; get{ return x; } }

Nope. First of all, you'd have to declare the setter like this in D: property int foo(int v) { return x = v; } so that you can write: int v = obj.foo = 1; // valid C# Next up is the issue of op-assign operations. In D, you can't do: obj.foo += 1; obj.foo++; while in C#, you can (it results in a get -> add 1 -> set and get -> inc -> set, etc).
 I think it is even perfectly fine to just allow function calls without
 parentheses, but I wouldn't mind seeing that feature gone.

 -  trusted  system

These are necessary.

They're far from necessary.

Why? Memory safety is generally considered to be important.
 - Exception handling - a lot of runtime, questionable value

I completely disagree. No exception handling means lots and lots and lots of boilerplate code for checking error codes, return values, which are too tedious to write, which translates to many people leaving them out and ending up with unreliable code that fail silently or crash outright when a function call they assumed would work stopped working. If you've worked in large multi-person projects, you'll see very quickly why you *need* exception handling. No modern language can do without exception handling. Maybe you have a beef with how it's currently done in D, but regardless, you *need* exception handling of some kind.

The exception handling system via try/catch is as bad and tedious as error codes, except the added runtime.

It can improve performance though, because the exceptional branches don't occur in the code that is normally executed.
 It all roots from the idea "catch everything that throws".
 This is broken, as you DON'T always need to
 handle all sorts of errors (letting it segfault or something sometimes
 simply proves to be better than trying to save the situation;

Except that it won't necessarily segfault. That is not how _reliable_ systems work. Robustness is an important property of critical systems. If your software might kill people if it behaves in the wrong way, you really really don't want to ignore error conditions.
 or you can simply assert it).

Certainly, if it is a consistency criterion internal to the program, then assertions should be used.
 Also http://yosefk.com/c++fqa/exceptions.html#fqa-17.1
 [snip.]

The part of this article relevant for D is this: "Still, in many cases, the benefits of exceptions are more important than their problems. For example, if your language manages memory automatically, the problem of releasing acquired resources becomes a small one (you only have to care about files, etc., which are a tiny part of the "resources" used by a program - most of the "resources" are memory). If your language throws exceptions when you violate its rules (for example, upon out-of-bounds array access), these exceptions will help you find lots of bugs, especially if you can get the call stack from an exception. If the purpose of an application is automated testing, and/or it's used as a quick-and-dirty internal tool as opposed to a product for an end user, this kind of exceptions is all you need to handle errors of almost all kinds. In some languages, you can even resume the execution from the point where the exception was raised after fixing the problem at the point where it was caught." Anyway, I generally avoid exceptions if they are not an obvious fit.

-- - Alex
Apr 29 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-04-2012 22:16, Andrej Mitrovic wrote:
 On 4/29/12, Alex Rřnne Petersen<xtzgzorex gmail.com>  wrote:
 Next up is the issue of op-assign operations. In D, you can't do:

 obj.foo += 1;
 obj.foo++;

 while in C#, you can (it results in a get ->  add 1 ->  set and get ->  inc
 ->  set, etc).

It's great to see another (successful) language implemented this. Do we have a proposal open for this somewhere?

AFAIK no. -- - Alex
Apr 29 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 10:03 PM, Alex Rønne Petersen wrote:
 On 28-04-2012 23:41, Timon Gehr wrote:
 As I understand it, the 'agreed upon' design is that

  property int foo() { return x; }
  property void foo(int v) { x = v; }

 Would be completely equivalent to C#:

 int foo { set{ x = value; }; get{ return x; } }

Nope. First of all, you'd have to declare the setter like this in D: property int foo(int v) { return x = v; } so that you can write: int v = obj.foo = 1; // valid C# Next up is the issue of op-assign operations. In D, you can't do: obj.foo += 1; obj.foo++; while in C#, you can (it results in a get -> add 1 -> set and get -> inc -> set, etc).

I didn't say this was how it worked in the current compiler implementation. But I may be wrong on what is the design because I didn't take part in that discussion. Notably, read-update operations now work on the built-in length property of arrays. I don't think there is any justification for not implementing this for properties.
Apr 29 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-29 22:16, Andrej Mitrovic wrote:
 On 4/29/12, Alex Rřnne Petersen<xtzgzorex gmail.com>  wrote:
 Next up is the issue of op-assign operations. In D, you can't do:

 obj.foo += 1;
 obj.foo++;

 while in C#, you can (it results in a get ->  add 1 ->  set and get ->  inc
 ->  set, etc).

It's great to see another (successful) language implemented this. Do we have a proposal open for this somewhere?

I think someone started to work on this. I have no idea what happened to it though. -- /Jacob Carlborg
Apr 30 2012
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 4/29/2012 6:05 AM, q66 wrote:

 I find versions sorta neat... and they're simple enough that they don't
 add to much bloat to the language. (Whereas if you added AND and OR to
 them, then they start duplicating the function of static if, and that's
 when they become redundant.)

They're nearly unusable now. And the syntax simply makes no sense.
 T


Someone forgot to tell me how unusable they are, because I've been using them for years. Quite sensibly.
Apr 28 2012
prev sibling next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"SomeDude" <lovelydear mailmetrash.com> wrote in message 
news:sxzgfzztxfvsstwrqdiu forum.dlang.org...
 On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
 On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:

So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?

Sorry, with that, I agree. Nick Sabalausky proposed to remove version entirely. But I agree there could be something like: version(LINUX|OSX){ ... } else { ... }

FWIW, one of the big wins I see in migrating "version" to "static if" is switching from the clumbsy "defined/undefined" model to a model of "true/false, undefined is an error". The current "undefined is not an error" stuff is just so...ActionScript 2.
Apr 28 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-28 21:22, q66 wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

- AAs integrated in the language; you barely ever use AA literals and having them purely in Phobos would help get rid of the runtime fat, as well as better implementations - Phobos is too fat - it needs to shrink to just a few core modules, others being distributed via some system like CPAN for Perl - Properties - they're kinda broken at this point and the value is questionable - trusted system - Exception handling - a lot of runtime, questionable value - Versions - not redundant, but needs a better system (with AND/OR, possibility of de-versioning, the assignment op to set versions is kinda bad) I think I would find some more, but these are the ones I can recall now.

As others have said, I think this is crazy. -- /Jacob Carlborg
Apr 29 2012
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 28-04-2012 23:18, SomeDude wrote:
 On Saturday, 28 April 2012 at 21:05:12 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
 [...]
 - AAs integrated in the language; you barely ever use AA literals and
 having them purely in Phobos would help get rid of the runtime fat, as
 well as better implementations

On the contrary, AA's are a major reason I started programming in D. In this day and age, it's simply inexcusable to *not* have some kind of hash type available by default.

Besides AA literals, library can handle this JUST FINE.

Yeah, but core language AA are so useful it would be a MAJOR mistake to remove them. In Python too, you could put the AA in the libraries. Yet everybody uses the AA that are in the language. Where I DO agree with you is, Phobos should be a two level library, i.e a minimalistic library, with about the same feature set as the standard C library + multithreading, and a superset with the full range of features (ranges, algorithms, etc). I've already advocated it somewhere else.

Let's get a standard package manager that we either advocate on dlang.org or include in the releases before we start talking about reducing the amount of modules in Phobos. -- - Alex
Apr 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-30 00:07, Manu wrote:
 On 29 April 2012 23:00, Alex Rønne Petersen <xtzgzorex gmail.com
 <mailto:xtzgzorex gmail.com>> wrote:

     Let's get a standard package manager that we either advocate on
     dlang.org <http://dlang.org> or include in the releases before we
     start talking about reducing the amount of modules in Phobos.


 Oh hell yes! I have exciting dreams of something like this every other
 night ;)

I'm working on this. Unfortunately I cannot work on this full-time so basically nothing gets done. https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D https://github.com/jacob-carlborg/orbit -- /Jacob Carlborg
Apr 30 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-30 09:32, simendsjo wrote:

 Vibe.d has its own:
 https://github.com/rejectedsoftware/vibe.d/tree/master/source/vibe/vpm
 And we have dsss: https://github.com/apriori/dsss

"This project is currently on ice in favor of porting orbit from D1 to D2 and continue its implemention. Orbit will cover the same featureset as dsss and much more." BTW, Orbit is already ported to D2.
 And it seems this might be related too:
 https://github.com/dbuilder-developers/dbuilder

This seems to be a build tool and not a package manager.
 Getting orbit up and running would have been great.

-- /Jacob Carlborg
Apr 30 2012
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/28/12, Walter Bright <newshound2 digitalmars.com> wrote:
 What's your list?

I don't mind extra features, just as long as they're properly documented and implemented. For example, I have absolutely no uses for anonymous classes right now, but I know DWT2 uses them and probably other people do use them. Personally I find the hardest threads to to follow are the ones discussing in/out/inout/autoref. For one thing there are compiler bugs, but then there are misconceptions between what developers vs documentation vs core devs say about them. And then you mix in classes and templates into the story and it all becomes a large forest of information that is very hard to digest. Another feature I'm curious about is .dup/.idup. It's basically hardcoded for a couple of types, but why not instead use UFCS and implement .dup/.idup in std.array as a free function? Then you might even use it for user-types by requiring a type to implement .dup/.idup functions. Also there's mixin templates. What exactly is the difference between mixin templates and regular templates? We can use the mixin statement for both types right now, so there doesn't seem to be a distinction. For example, if you take samples from the template mixin page (http://dlang.org/template-mixin.html) and you remove "mixin" from the template declaration, all of the samples will continue to work. You could remove this declaration feature right now and you probably wouldn't break any code at all. Seems like low-hanging fruit to me.
Apr 28 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2012 12:36 PM, Andrej Mitrovic wrote:
 Also there's mixin templates. What exactly is the difference between
 mixin templates and regular templates?

A mixin template is instantiated in context of the instantiation point, while a regular template is instantiated in the context of the template definition point. This becomes relevant when looking up symbols that are not defined within the template.
Apr 28 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 10:02 PM, Walter Bright wrote:
 On 4/28/2012 12:36 PM, Andrej Mitrovic wrote:
 Also there's mixin templates. What exactly is the difference between
 mixin templates and regular templates?

A mixin template is instantiated in context of the instantiation point, while a regular template is instantiated in the context of the template definition point. This becomes relevant when looking up symbols that are not defined within the template.

The implementation seems to disagree: int x; template X(){ // not a mixin template void y(){x=2;} } class C{ int x; mixin X; // picks up local 'x' } void main(){ auto c = new C; c.y(); import std.stdio; writeln(x," ",c.x); // "0 2" } Or am I misunderstanding your statement?
Apr 28 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2012 1:32 PM, Timon Gehr wrote:
 On 04/28/2012 10:02 PM, Walter Bright wrote:
 On 4/28/2012 12:36 PM, Andrej Mitrovic wrote:
 Also there's mixin templates. What exactly is the difference between
 mixin templates and regular templates?

A mixin template is instantiated in context of the instantiation point, while a regular template is instantiated in the context of the template definition point. This becomes relevant when looking up symbols that are not defined within the template.

The implementation seems to disagree: int x; template X(){ // not a mixin template void y(){x=2;} } class C{ int x; mixin X; // picks up local 'x'

Makes it a mixin template.
 }

 void main(){
 auto c = new C;
 c.y();
 import std.stdio;
 writeln(x," ",c.x); // "0 2"
 }

 Or am I misunderstanding your statement?

The behavior is as I described.
Apr 30 2012
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 04/30/12 02:33, Simen Kjaeraas wrote:
 On Sat, 28 Apr 2012 22:40:10 +0200, Artur Skawina <art.08.09 gmail.com> wrote:
 
 On 04/28/12 22:02, Walter Bright wrote:
 On 4/28/2012 12:36 PM, Andrej Mitrovic wrote:
 Also there's mixin templates. What exactly is the difference between
 mixin templates and regular templates?

A mixin template is instantiated in context of the instantiation point, while a regular template is instantiated in the context of the template definition point. This becomes relevant when looking up symbols that are not defined within the template.

Yeah, but this was actually the only suggestion so far in this thread that i could agree with... The issue is template t1() { int a = b; } int main() { int b; mixin t1; return a; } which is currently accepted - and would enforcing the mixin annotation really help anything? artur

At least some of us want mixin templates to be marked mixin at declaration point, and usable without 'mixin': mixin template A( ) { int n; } struct S { A!(); }

Yes, that's the other possible use for marking a template as a mixin. Unlike my above example it wouldn't then be redundant; the question is however if this functionality really is desirable... mixin template t1() { auto _ = a = b; } int main() { int a, b=1; t1!(); return a; } This program would now return '1', which can be non-obvious if you don't know the definition of 't1'. Right now you have to write that as template t1() { auto _ = a = b; } int main() { int a, b=1; mixin t1!(); return a; } so the mixin is clearly visible. These kind of template macros would be useful and i'd like to have them too, but there is a cost, and i'm not yet sure that being able to omit the 'mixin' keyword would be worth it. artur
Apr 29 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 04/28/12 22:02, Walter Bright wrote:
 On 4/28/2012 12:36 PM, Andrej Mitrovic wrote:
 Also there's mixin templates. What exactly is the difference between
 mixin templates and regular templates?

A mixin template is instantiated in context of the instantiation point, while a regular template is instantiated in the context of the template definition point. This becomes relevant when looking up symbols that are not defined within the template.

Yeah, but this was actually the only suggestion so far in this thread that i could agree with... The issue is template t1() { int a = b; } int main() { int b; mixin t1; return a; } which is currently accepted - and would enforcing the mixin annotation really help anything? artur
Apr 28 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-28 21:36, Andrej Mitrovic wrote:
 On 4/28/12, Walter Bright<newshound2 digitalmars.com>  wrote:
 What's your list?

I don't mind extra features, just as long as they're properly documented and implemented. For example, I have absolutely no uses for anonymous classes right now, but I know DWT2 uses them and probably other people do use them.

If a anonymous classes where remove from D, life would get even harder for DWT.
 Personally I find the hardest threads to to follow are the ones
 discussing in/out/inout/autoref. For one thing there are compiler
 bugs, but then there are misconceptions between what developers vs
 documentation vs core devs say about them. And then you mix in classes
 and templates into the story and it all becomes a large forest of
 information that is very hard to digest.

Agree.
 Another feature I'm curious about is .dup/.idup. It's basically
 hardcoded for a couple of types, but why not instead use UFCS and
 implement .dup/.idup in std.array as a free function? Then you might
 even use it for user-types by requiring a type to implement .dup/.idup
 functions.

Agree with this one as well. -- /Jacob Carlborg
Apr 29 2012
prev sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 28-04-2012 21:36, Andrej Mitrovic wrote:
 On 4/28/12, Walter Bright<newshound2 digitalmars.com>  wrote:
 What's your list?

I don't mind extra features, just as long as they're properly documented and implemented. For example, I have absolutely no uses for anonymous classes right now, but I know DWT2 uses them and probably other people do use them.

I use them too. They're useful if you have an abstract method that just needs to return an arbitrary object implementing some interface or whatever.
 Personally I find the hardest threads to to follow are the ones
 discussing in/out/inout/autoref. For one thing there are compiler
 bugs, but then there are misconceptions between what developers vs
 documentation vs core devs say about them. And then you mix in classes
 and templates into the story and it all becomes a large forest of
 information that is very hard to digest.

 Another feature I'm curious about is .dup/.idup. It's basically
 hardcoded for a couple of types, but why not instead use UFCS and
 implement .dup/.idup in std.array as a free function? Then you might
 even use it for user-types by requiring a type to implement .dup/.idup
 functions.

This seems reasonable to me.
 Also there's mixin templates. What exactly is the difference between
 mixin templates and regular templates? We can use the mixin statement
 for both types right now, so there doesn't seem to be a distinction.
 For example, if you take samples from the template mixin page
 (http://dlang.org/template-mixin.html) and you remove "mixin" from the
 template declaration, all of the samples will continue to work. You
 could remove this declaration feature right now and you probably
 wouldn't break any code at all. Seems like low-hanging fruit to me.

-- - Alex
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:
 - AAs integrated in the language; you barely ever use AA 
 literals and having them purely in Phobos would help get rid of 
 the runtime fat, as well as better implementations
 - Phobos is too fat - it needs to shrink to just a few core 
 modules, others being distributed via some system like CPAN for 
 Perl
 - Properties - they're kinda broken at this point and the value 
 is questionable
 -  trusted  system
 - Exception handling - a lot of runtime, questionable value
 - Versions - not redundant, but needs a better system (with 
 AND/OR, possibility of de-versioning, the assignment op to set 
 versions is kinda bad)

 I think I would find some more, but these are the ones I can 
 recall now.

I disagree with every single point here.
Apr 28 2012
prev sibling next sibling parent reply "foobar" <foo bar.com> writes:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was which features in D are redundant and/or 
 do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble and creal types.

 What's your list?

D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse). This is nothing more than a fancy function with a delegate parameter. * enum - enum should be completely redesigned to only implement what it's named after: enumerations. * version - this does not belong in a programming language. Git is a much better solution. * di files - a library should encapsulate all the info required to use it. Java Jars, .Net assemblies and even old school; Pascal units all solved this long ago. * This is a big one: get rid of *all* current compile time special syntax. It should be replaced by a standard compilation API and the compiler should be able to use plugins/addons. This would reduce the size of the language to half of its current size, maybe even more.
Apr 28 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 09:58 PM, foobar wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse).

foreach is very useful. Have you actually used D?
 This is nothing more than a fancy function with
 a delegate parameter.

That would be opApply.
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

What is the benefit?
 * version - this does not belong in a programming language. Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; Pascal
 units all solved this long ago.

 * This is a big one: get rid of *all* current compile time
 special syntax.

What would that be exactly?
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?
 This would reduce the size of the language to half of its current
 size, maybe even more.

I am certain that it would not. You missed to present the 'general purpose mechanisms'.
Apr 28 2012
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29.04.2012 3:25, foobar wrote:
 On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse).

foreach is very useful. Have you actually used D?

I have used D and didn't claim that foreach isn't useful. What I said that is that it belongs in the library, NOT the language.

C++ was criticized for a long time for NOT having foreach in the language. Now they have http://www2.research.att.com/~bs/C++0xFAQ.html#for. Also people were so desperate to gave it that even this http://www.boost.org/doc/libs/1_49_0/doc/html/foreach.html was considered a nice addition to boost (and still part of it). Obviously somehow you want to go into the opposite direction. Beats me. -- Dmitry Olshansky
Apr 28 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 01:25 AM, foobar wrote:
 On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse).

foreach is very useful. Have you actually used D?

I have used D and didn't claim that foreach isn't useful. What I said that is that it belongs in the library, NOT the language.

Therefore you say that it is not useful as a language feature.
 This is nothing more than a fancy function with
 a delegate parameter.

That would be opApply.

Indeed but I'd go even further by integrating it with ranges so that ranges would provide an opApply like method e.g. auto r = BinaryTree!T.preOrder(); // returns range r.each( (T elem) { ...use elem...}); // each method a-la Ruby

Well, I don't think this is better than built-in foreach (with full break and continue and goto even for user-defined opApply!)
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

What is the benefit?

On the one hand the current enum for manifest constants is a hack due to weaknesses of the toolchain

I think that is actually not true. It might have been the original motivation, but it has gone beyond that. Which weaknesses in particular? I don't think that the toolchain can be improved in any way in this regard.
 and on the other hand it doesn't provide
 properly encapsulated enums

Those could in theory be added without removing the manifest constant usage.
 such as for instance the Java 5.0 ones or
 the functional kind.

An algebraic data type is not an 'enumeration', so this is a moot point.
 * version - this does not belong in a programming language. Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

It is far better than having a pile of #ifdef styled spaghetti code. I'd expect to have all the OS specific code encapsulated separately anyway, not spread around the code base. Which is the current recommended way of using versions anyway. The inevitable conclusion would be to either use a version management system like git or have separate implementation modules for platform specific code and use the build tool to implement the logic of select the modules to include in the build.

Which projects you are aware of actually use this kind of versioning?
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; Pascal
 units all solved this long ago.

 * This is a big one: get rid of *all* current compile time
 special syntax.

What would that be exactly?

This includes __traits, templates, static ifs, etc..

This is what makes D useful to me.
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?

No I'm joking. The current system is a pile of hacks on top of the broken model of c++ templates. I should be able to use a *very* minimalistic system to write completely _regular_ D code and run it at different times.

Examples in concrete syntax? How would you replace eg. string mixin functionality?
 This is a simple matter
 of separation of concerns: what we want to execute (what code) is
 separate to the concern of when we want to execute it.

It is not. For example, code that is only executed during CTFE does never have to behave gracefully if the input is ill-formed.
Apr 29 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 11:31 AM, foobar wrote:
 On Sunday, 29 April 2012 at 08:58:24 UTC, Timon Gehr wrote:
 [...]
 Indeed but I'd go even further by integrating it with ranges so that
 ranges would provide an opApply like method e.g.
 auto r = BinaryTree!T.preOrder(); // returns range
 r.each( (T elem) { ...use elem...}); // each method a-la Ruby

Well, I don't think this is better than built-in foreach (with full break and continue and goto even for user-defined opApply!)

I think we reached a matter of taste here.

Certainly, and this applies to the other issues as well.
 How often do you use these features anyway in your regular code?

Not too often, but it is awesome that it actually works. ;)
 I prefer a more functional style
 with higher order functions (map/reduce/filter/etc..) so for me foreach
 is about applying something to all elements and doesn't entail usage of
 break/continue/etc..

Some algorithms are better expressed in functional terms, some algorithms are better expressed in imperative terms. I think a combination of the two usually is the best choice.
 I'll use these constructs in a for loop but not a foreach loop.

break can be used as an optimisation to stop execution of a loop that performs a 'reduce' if the result cannot change after a certain point. I use continue mostly for 'filter'-ing out elements from consideration. Usually there is not a huge difference between imperative style and functional style loops.
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

What is the benefit?

On the one hand the current enum for manifest constants is a hack due to weaknesses of the toolchain

I think that is actually not true. It might have been the original motivation, but it has gone beyond that. Which weaknesses in particular? I don't think that the toolchain can be improved in any way in this regard.

The weakness as far as I know is about link time optimization of constants. But regardless, my ideal implementation of so called "compile-time" features, including compile time constants, would be very different anyway.

Well, you never elaborate on these things. BTW, what is your stance on template haskell?
 and on the other hand it doesn't provide
 properly encapsulated enums

Those could in theory be added without removing the manifest constant usage.
 such as for instance the Java 5.0 ones or
 the functional kind.

An algebraic data type is not an 'enumeration', so this is a moot point.

I disagree. They are a generalization of the concept. In fact, functional languages such as ML implement c style enums as an algebraic data type.

The current way enums can be used as manifest constants is a generalization as well. The generalization takes place on the static semantics level instead of on the conceptual level though.
 [...]

 I should be able to use a *very* minimalistic system to write completely
 _regular_ D code and run it at different times.

Examples in concrete syntax? How would you replace eg. string mixin functionality?


?
 This is a simple matter
 of separation of concerns: what we want to execute (what code) is
 separate to the concern of when we want to execute it.

It is not. For example, code that is only executed during CTFE does never have to behave gracefully if the input is ill-formed.

I disagree - you should make sure the input is valid or all sorts of bad things could potentially happen such as a compiler can get stuck in an infinite loop.

It could fail in a number of other ways. I don't think that this example can be used to invalidate the statement.
 If you only use a batch mode compiler you can simply kill
 the process which btw applies just the same to your user program.

Maybe the user program should not be killed. See your IDE example.
 However, if you use an integrated compiler in your IDE that could cause
 me to lose part of my work if the IDE crashes.

Why would the IDE crash?
Apr 29 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 02:17 PM, foobar wrote:
 On Sunday, 29 April 2012 at 11:23:17 UTC, Timon Gehr wrote:
 break can be used as an optimisation to stop execution of a loop that
 performs a 'reduce' if the result cannot change after a certain point.
 I use continue mostly for 'filter'-ing out elements from consideration.

Well, I'll use a filter to filter out elements.... :)

The filter condition is not always conveniently expressed in terms of a lambda function.
 ...
 The current way enums can be used as manifest constants is a
 generalization as well. The generalization takes place on the static
 semantics level instead of on the conceptual level though.

A language is the interface between a human programmer and a computer and should IMO provide clear conceptual level abstractions for the benefit of the human. I realize that using enum for manifest constants makes sense on the implementation level but I feel the compiler should work for me and not the other way around.

Well, I don't think that 'enum' for manifest constants asks a lot from the programmer, but YMMV.
 ...
 macro testMacro() {
  std.writeln("Hello world!");
  <| std.writeln("Hello world!"); |>
 }

 macro is a syntactic sugar on top of a regular function. You can call it
 just like you call a regular function. The first line is executed
 regularly and the second one is mixed-in [returned token stream from the
 macro]
 since the macro is evaluated by the compiler, the first line would
 generate compile-time output. the second line would be part of the
 generated code and would be thus executed during run-time of my code.

 Regarding syntax, the main difference is that it's a token stream and
 not text but otherwise pretty much the same as current CTFE. The
 important difference here is the execution model which is different from
 CTFE.

We have the 'macro' keyword ;). Probably it should just be a built-in primitive type of the language that represents an AST?
Apr 29 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-28 22:43, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?

Have a look at what Scala have done. They basically have the complete compiler available as a library. Then they used this library to implement runtime reflection and macros. Macros in Scala are functions that execute at compile time. -- /Jacob Carlborg
Apr 29 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 04:53 PM, Jacob Carlborg wrote:
 On 2012-04-28 22:43, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?

Have a look at what Scala have done. They basically have the complete compiler available as a library. Then they used this library to implement runtime reflection and macros. Macros in Scala are functions that execute at compile time.

It is not as powerful as what we have in D and it requires invoking the compiler multiple times.
Apr 29 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-29 18:28, Timon Gehr wrote:
 On 04/29/2012 04:53 PM, Jacob Carlborg wrote:
 On 2012-04-28 22:43, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?

Have a look at what Scala have done. They basically have the complete compiler available as a library. Then they used this library to implement runtime reflection and macros. Macros in Scala are functions that execute at compile time.

It is not as powerful as what we have in D and it requires invoking the compiler multiple times.

That's the whole point, there won't be any special case for CTFE. BTW, isn't that basically the same as having a built-in interpreter? -- /Jacob Carlborg
Apr 29 2012
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 28-04-2012 22:43, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse).

foreach is very useful. Have you actually used D?

Removing it would be craziness.
 This is nothing more than a fancy function with
 a delegate parameter.

That would be opApply.
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

What is the benefit?
 * version - this does not belong in a programming language. Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

That is absolutely horrible. It's not how branches are meant to be used.
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; Pascal
 units all solved this long ago.

 * This is a big one: get rid of *all* current compile time
 special syntax.

What would that be exactly?
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?
 This would reduce the size of the language to half of its current
 size, maybe even more.

I am certain that it would not. You missed to present the 'general purpose mechanisms'.

-- - Alex
Apr 29 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 01:25, foobar wrote:
 On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse).

foreach is very useful. Have you actually used D?

I have used D and didn't claim that foreach isn't useful. What I said that is that it belongs in the library, NOT the language.

Yeah, we tried that in C++. It sucked. The reason it works for many functional languages is that they have even more terse syntax than D. It would suck to make foreach a function in D.
 This is nothing more than a fancy function with
 a delegate parameter.

That would be opApply.

Indeed but I'd go even further by integrating it with ranges so that ranges would provide an opApply like method e.g. auto r = BinaryTree!T.preOrder(); // returns range r.each( (T elem) { ...use elem...}); // each method a-la Ruby
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

What is the benefit?

On the one hand the current enum for manifest constants is a hack due to weaknesses of the toolchain and on the other hand it doesn't provide properly encapsulated enums such as for instance the Java 5.0 ones or the functional kind.
 * version - this does not belong in a programming language. Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

It is far better than having a pile of #ifdef styled spaghetti code. I'd expect to have all the OS specific code encapsulated separately anyway, not spread around the code base. Which is the current recommended way of using versions anyway. The inevitable conclusion would be to either use a version management system like git or have separate implementation modules for platform specific code and use the build tool to implement the logic of select the modules to include in the build.

Yeah, we tried that in C and C++. It sucked. See: Autotools.
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; Pascal
 units all solved this long ago.

 * This is a big one: get rid of *all* current compile time
 special syntax.

What would that be exactly?

This includes __traits, templates, static ifs, etc..
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?

No I'm joking. The current system is a pile of hacks on top of the broken model of c++ templates. I should be able to use a *very* minimalistic system to write completely _regular_ D code and run it at different times. This is a simple matter of separation of concerns: what we want to execute (what code) is separate to the concern of when we want to execute it.
 This would reduce the size of the language to half of its current
 size, maybe even more.

I am certain that it would not. You missed to present the 'general purpose mechanisms'.


-- - Alex
Apr 29 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 12:18, foobar wrote:
 Meta comment: C++ is the spawn of the devil so I don't accept anything
 related to c++ as a valid argument.

 On Sunday, 29 April 2012 at 20:09:34 UTC, Alex Rønne Petersen wrote:
 [...]
 I have used D and didn't claim that foreach isn't useful.
 What I said that is that it belongs in the library, NOT the language.

Yeah, we tried that in C++. It sucked.

See meta comment above.
 The reason it works for many functional languages is that they have
 even more terse syntax than D. It would suck to make foreach a
 function in D.

D wants to support functional programming. That means we should provide whatever is necessary to write functional style code including foreach methods. IF D can't properly implement a FP foreach method (And IMO it *can*) than we have failed.

Of course it can, but not with type inference, unless you templatize it. That is: void forEach(alias fun, R)(R range) { // ... } enjoys type inference: forEach!(item => foo(item))(myRange); But this doesn't: void forEach(R)(R range, scope void delegate(ElementType!R) dg) { // ... } This won't work: forEach(myRange, item => foo(item)); You have to do: forEach(myRange, (ElementType!(typeof(myRange)) => foo(item)); which, frankly, sucks.
 * version - this does not belong in a programming language. Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

It is far better than having a pile of #ifdef styled spaghetti code. I'd expect to have all the OS specific code encapsulated separately anyway, not spread around the code base. Which is the current recommended way of using versions anyway. The inevitable conclusion would be to either use a version management system like git or have separate implementation modules for platform specific code and use the build tool to implement the logic of select the modules to include in the build.

Yeah, we tried that in C and C++. It sucked. See: Autotools.

see meta comment above. The fact that you used a horribly designed language with a horrible mess of a "build tool" made out of shell scripts IIRC is not an indication that the language should include build-tool functionality.

-- - Alex
Apr 30 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 05:13 PM, Alex Rønne Petersen wrote:
 On 30-04-2012 12:18, foobar wrote:
 Meta comment: C++ is the spawn of the devil so I don't accept anything
 related to c++ as a valid argument.

 On Sunday, 29 April 2012 at 20:09:34 UTC, Alex Rønne Petersen wrote:
 [...]
 I have used D and didn't claim that foreach isn't useful.
 What I said that is that it belongs in the library, NOT the language.

Yeah, we tried that in C++. It sucked.

See meta comment above.
 The reason it works for many functional languages is that they have
 even more terse syntax than D. It would suck to make foreach a
 function in D.

D wants to support functional programming. That means we should provide whatever is necessary to write functional style code including foreach methods. IF D can't properly implement a FP foreach method (And IMO it *can*) than we have failed.

Of course it can, but not with type inference, unless you templatize it. That is: void forEach(alias fun, R)(R range) { // ... } enjoys type inference: forEach!(item => foo(item))(myRange); But this doesn't: void forEach(R)(R range, scope void delegate(ElementType!R) dg) { // ... } This won't work: forEach(myRange, item => foo(item)); You have to do: forEach(myRange, (ElementType!(typeof(myRange)) => foo(item)); which, frankly, sucks.

I agree. It is due to the fact that currently actually no inference takes place, it is just simple deduction. It shouldn't be very hard to add that functionality.
Apr 30 2012
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 01:49, SomeDude wrote:
 On Saturday, 28 April 2012 at 23:25:10 UTC, foobar wrote:
 On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse).

foreach is very useful. Have you actually used D?

I have used D and didn't claim that foreach isn't useful. What I said that is that it belongs in the library, NOT the language.

Well, it's your opinion. But I bet it's not the opinion of thousands of programmers, it's not the opinion of the Java/C# designers, and I even believe they wanted to add foreach in C++ (or is it already the case ?). Putting things in the library isn't the solution for everything: it's often hard (if possible) to make it work as well as in the core language, and error messages are usually more cryptic. Basic features like this should stay in the core language in my opinion.

C++11 has range-based for (which is basically foreach).
 This is nothing more than a fancy function with
 a delegate parameter.

That would be opApply.

Indeed but I'd go even further by integrating it with ranges so that ranges would provide an opApply like method e.g. auto r = BinaryTree!T.preOrder(); // returns range r.each( (T elem) { ...use elem...}); // each method a-la Ruby
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

What is the benefit?

On the one hand the current enum for manifest constants is a hack due to weaknesses of the toolchain and on the other hand it doesn't provide properly encapsulated enums such as for instance the Java 5.0 ones or the functional kind.
 * version - this does not belong in a programming language. Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

It is far better than having a pile of #ifdef styled spaghetti code. I'd expect to have all the OS specific code encapsulated separately anyway, not spread around the code base. Which is the current recommended way of using versions anyway. The inevitable conclusion would be to either use a version management system like git or have separate implementation modules for platform specific code and use the build tool to implement the logic of select the modules to include in the build.

No it isn't. Ask the kernel hackers why they still use #ifdef instead of using hundreds of git branches for every feature and platform they must maintain.
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; Pascal
 units all solved this long ago.

 * This is a big one: get rid of *all* current compile time
 special syntax.

What would that be exactly?

This includes __traits, templates, static ifs, etc..
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?

No I'm joking. The current system is a pile of hacks on top of the broken model of c++ templates. I should be able to use a *very* minimalistic system to write completely _regular_ D code and run it at different times. This is a simple matter of separation of concerns: what we want to execute (what code) is separate to the concern of when we want to execute it.
 This would reduce the size of the language to half of its current
 size, maybe even more.

I am certain that it would not. You missed to present the 'general purpose mechanisms'.


You should use Go. It fits better to your views about programming languages than D.

-- - Alex
Apr 29 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-28 21:58, foobar wrote:

 D has a lot of ad-hock features which make the language
 needlessly large and complex. I'd strive to replace these with
 better general purpose mechanisms.

 My list:
 * I'd start with getting rid of foreach completely. (not just
 foreach_reverse). This is nothing more than a fancy function with
 a delegate parameter.

I agree.
 * This is a big one: get rid of *all* current compile time
 special syntax. It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons. This
 would reduce the size of the language to half of its current
 size, maybe even more.

I agree with this one as well. At least if the compiler would be implemented like this. -- /Jacob Carlborg
Apr 29 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter:

 which features in D are redundant and/or do not add significant 
 value?
...
 What's your list?

Finding things to remove now from D is hard, in my code I have used most D features now. And many suggestions I have seen in this thread are very bad, like removing foreach_reverse (that I use often), or "Phobos is too fat" (that is the opposite of what I'd like, I'd like D with more batteries). The features I have not used in my programs so far are: 1) Typesafe Variadic Functions for class objects (never used so far). 2) >>>= >>> (Never used so far). 3) Floating point comparison operators (never used). 4) Delimited Strings / heredoc strings (never used so far in real code, despite Perl programmers use them now and then). 5) lazy (as function argument. I have used "lazy" in some test programs, but not in real code so far). 6) Anonymous classes (used only in demo code so far). 7) Shortened floating point literals as .6 or 6. Other things that I don't like: 1) Mixed C/D array declarations (http://d.puremagic.com/issues/show_bug.cgi?id=5807 ) 2) I'd like to disallow (or fix!) default arguments of out and ref arguments (http://d.puremagic.com/issues/show_bug.cgi?id=5850 ). 3) Automatic joining of adjacent strings (a bug-prone anti-feature: ["red" "green", "blue"]). 4) Comma operator, it gives more troubles than flexibility. 5) The most complex parts of the is() syntax (to be replaced with other things). 6) Two kinds of tuples. I'd like a single tuple type in a language, but I understand this is hard to do. ------------------------- I'd also like to see some limits removed like: struct Foo {} void main() { auto f = new Foo; // currently not accepted, silly } BigInt x; switch (x) { case BigInt(0): break; default: } And I'd like some features added/improved, like: - tuple unpacking syntax; - computed gotos; - a static foreach (http://d.puremagic.com/issues/show_bug.cgi?id=4085 ); - attribute hiding error or warning (http://d.puremagic.com/issues/show_bug.cgi?id=5187 ); - safer typesafe variadics (http://d.puremagic.com/issues/show_bug.cgi?id=5212 ); - Named arguments; And few other things. Bye, bearophile
Apr 28 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2012 1:00 PM, bearophile wrote:
 "Phobos is too fat"

As opposed to Phobos being phat?
Apr 28 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
 On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:
 - AAs integrated in the language; you barely ever use AA 
 literals and having them purely in Phobos would help get rid 
 of the runtime fat, as well as better implementations
 - Phobos is too fat - it needs to shrink to just a few core 
 modules, others being distributed via some system like CPAN 
 for Perl
 - Properties - they're kinda broken at this point and the 
 value is questionable
 -  trusted  system
 - Exception handling - a lot of runtime, questionable value
 - Versions - not redundant, but needs a better system (with 
 AND/OR, possibility of de-versioning, the assignment op to set 
 versions is kinda bad)

 I think I would find some more, but these are the ones I can 
 recall now.

I disagree with every single point here.

So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?
Apr 28 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was which features in D are redundant and/or 
 do not add significant value?

A more general answer. From my experience the real problem with language features is not their high number, because I am able to learn hundreds of them well. The main problem comes from bad/broken interaction between features, hard to see side effects of features, and so on. Bye, bearophile
Apr 28 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Saturday, 28 April 2012 at 20:04:11 UTC, Walter Bright wrote:
 On 4/28/2012 1:00 PM, bearophile wrote:
 "Phobos is too fat"

As opposed to Phobos being phat?

Well my concern is so that it doesn't end up like Python standard library, half-bitrotting and half-crap :) Huge standard library is not a good idea even for a very big language/library team, and D doesn't have one.
Apr 28 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
 On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:

So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?

Sorry, with that, I agree. Nick Sabalausky proposed to remove version entirely. But I agree there could be something like: version(LINUX|OSX){ ... } else { ... }
Apr 28 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 08:47 PM, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

- Associative array literals as non-associative array initializers [1] - C style array declarations [2] - 'align' declaration [3] - 'synchronized' [4] - special treatment of built-in types during parsing [5] - the arcane restrictions on which exact kind of argument can be used to substitute which kind of template parameter I think all other language features are useful and except for new instance.Class and 'this' template parameters, I think they all occur in my code. (But those would certainly come in handy for a somewhat more OO-like style of programming.) (There are a few features that I'd like to give a (mostly syntactic) overhaul, but that is not what is discussed here.) Explanations: [1] Actually I think the functionality is very useful, but the syntax is probably confusing for many fellow D programmers. CTFE should enable a library implementation. [2] They violate the 'same syntax, same behaviour' rule, and they don't add a lot of value. [3] I have not understood until now what exactly the guarantees are that it gives, so take this with a grain of salt. I know that it is not useful as implemented DMD for typical alignment tasks, and that GDC implements different semantics. Can you explain to me what it is useful for? [4] It adds memory overhead for the monitor to every single class, even though most classes are explicitly _typed_ as unshared. [5] It is for example impossible to directly string mixin "int".
Apr 28 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 10:24 PM, Timon Gehr wrote:
 On 04/28/2012 08:47 PM, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

- Associative array literals as non-associative array initializers [1] - C style array declarations [2] - 'align' declaration [3] - 'synchronized' [4] - special treatment of built-in types during parsing [5] - the arcane restrictions on which exact kind of argument can be used to substitute which kind of template parameter

Oh, completely forgot about that one: - 'in' operator returning a pointer to the element.
Apr 28 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 06:36 AM, Andrej Mitrovic wrote:
 On 4/29/12, Timon Gehr<timon.gehr gmx.ch>  wrote:
 - 'in' operator returning a pointer to the element.

AFAIK this is a property of how the opIn_r function is implemented, nothing much to do with the language itself.

Well, AAs are part of the language.
 But it does allow for some neat tricks, like:

      int[int] hash;
      hash[1] = 2;
      int value = *enforce(1 in hash, new Exception("1 not in hash"));
      assert(value == 2);
 or:
      if (auto val = 1 in hash)
          ...use val pointer (+ if it's a class/struct pointer you still
 have access to the dot syntax)
      else
          ... errors..

I know, but 'in' is somewhat of a misnomer. Anyway, it is not a huge issue.
Apr 29 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-04-2012 00:49, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 12:39:03AM +0200, Timon Gehr wrote:
 On 04/28/2012 10:24 PM, Timon Gehr wrote:
 On 04/28/2012 08:47 PM, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

- Associative array literals as non-associative array initializers [1] - C style array declarations [2] - 'align' declaration [3] - 'synchronized' [4] - special treatment of built-in types during parsing [5] - the arcane restrictions on which exact kind of argument can be used to substitute which kind of template parameter

Oh, completely forgot about that one: - 'in' operator returning a pointer to the element.

Yeah that one elicited a WAT from me when I first started using it. Surprisingly enough, it sounded OK when I read it in TDPL, but when I started using it I realized just how b0rken it is. T

How so? It's seemed entirely reasonable to me. -- - Alex
Apr 29 2012
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-04-2012 06:36, Andrej Mitrovic wrote:
 On 4/29/12, Timon Gehr<timon.gehr gmx.ch>  wrote:
 - 'in' operator returning a pointer to the element.

AFAIK this is a property of how the opIn_r function is implemented, nothing much to do with the language itself.

I hate to nitpick and all that, but opBinaryRight!"in" actually works now. ;)
 But it does allow for some neat tricks, like:

      int[int] hash;
      hash[1] = 2;
      int value = *enforce(1 in hash, new Exception("1 not in hash"));
      assert(value == 2);
 or:
      if (auto val = 1 in hash)
          ...use val pointer (+ if it's a class/struct pointer you still
 have access to the dot syntax)
      else
          ... errors..

-- - Alex
Apr 29 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-04-2012 22:52, Andrej Mitrovic wrote:
 On 4/29/12, Andrej Mitrovic<andrej.mitrovich gmail.com>  wrote:
 struct Foo {
      auto opIn_r(string op)(int i) { return 1; }
 }

Sorry that's wrong, should be: struct Foo { auto opIn_r(int i) { return 1; } } And then you get: test.d(25): Error: function test.Foo.opIn_r (int i) is not callable using argument types (string) test.d(25): Error: cannot implicitly convert expression ("") of type string to int which much better than Bar's error message.

I think all of the error messages you posted could need improvement. In any case, that's a compiler issue if anything. -- - Alex
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 12:39:03AM +0200, Timon Gehr wrote:
 On 04/28/2012 10:24 PM, Timon Gehr wrote:
On 04/28/2012 08:47 PM, Walter Bright wrote:
Andrei and I had a fun discussion last night about this question. The
idea was which features in D are redundant and/or do not add significant
value?

A couple already agreed upon ones are typedef and the cfloat, cdouble
and creal types.

What's your list?

- Associative array literals as non-associative array initializers [1] - C style array declarations [2] - 'align' declaration [3] - 'synchronized' [4] - special treatment of built-in types during parsing [5] - the arcane restrictions on which exact kind of argument can be used to substitute which kind of template parameter

Oh, completely forgot about that one: - 'in' operator returning a pointer to the element.

Yeah that one elicited a WAT from me when I first started using it. Surprisingly enough, it sounded OK when I read it in TDPL, but when I started using it I realized just how b0rken it is. T -- People tell me that I'm paranoid, but they're just out to get me.
Apr 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 00:39:03 Timon Gehr wrote:
 Oh, completely forgot about that one:
 
 - 'in' operator returning a pointer to the element.

Really? I use that all the time with AAs. Without that, you would have to do two lookups to get an object which might not be in the container, so it would be less efficient. I'd hate it if in stopped returning a pointer. We'd just have to add some other function which does the exact same thing as in now, and then I'd use in a _lot_ less. - Jonathan M Davis
Apr 28 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 - 'in' operator returning a pointer to the element.

Really? I use that all the time with AAs. Without that, you would have to do two lookups to get an object which might not be in the container, so it would be less efficient.

LDC1 compiler introduced a small optimization, it looks for nearby associative array lookups and removes the second of them where possible. In my code I have seen this frees me to use "in" nearby followed by [], with the same efficiency of a single AA lookup. With this small optimization, D "in" is free to return a more clean boolean. This optimization doesn't work if you want to store the pointer returned by "in" to use it later, but in my code this pattern doesn't happen, I think it's quite uncommon. Java/JavaScript/Lua show that the language design has to focus on what's hard to optimize away for the compiler, like offering ways to the programmer to specify higher level semantics (like asserting: foo(a,b) is equal to foo(b,a)), instead of focusing on what a not dumb static compiler (not even a JIT) is able to optimize away. Bye, bearophile
Apr 28 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/29/12, Timon Gehr <timon.gehr gmx.ch> wrote:
 - 'in' operator returning a pointer to the element.

AFAIK this is a property of how the opIn_r function is implemented, nothing much to do with the language itself. But it does allow for some neat tricks, like: int[int] hash; hash[1] = 2; int value = *enforce(1 in hash, new Exception("1 not in hash")); assert(value == 2); or: if (auto val = 1 in hash) ...use val pointer (+ if it's a class/struct pointer you still have access to the dot syntax) else ... errors..
Apr 28 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/29/12, Alex R=F8nne Petersen <xtzgzorex gmail.com> wrote:
 I hate to nitpick and all that, but opBinaryRight!"in" actually works
 now. ;)

Yes and then you get to have those nice template instantiation errors, which make no sense at all: struct Foo { auto opIn_r(string op)(int i) { return 1; } } struct Bar { auto opBinaryRight(string op)(int i) { return 1; } } void main() { Foo foo; auto x =3D "" in foo; Bar bar; auto y =3D "" in bar; } Foo: test.d(34): Error: template test.Foo.opIn_r does not match any function template declaration test.d(16): Error: template test.Foo.opIn_r(string op) cannot deduce template function from argument types !()(string) Bar: test.d(37): Error: rvalue of in expression must be an associative array, no= t Bar The Bar error message is completely useless.
Apr 29 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/29/12, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 struct Foo {
     auto opIn_r(string op)(int i) { return 1; }
 }

Sorry that's wrong, should be: struct Foo { auto opIn_r(int i) { return 1; } } And then you get: test.d(25): Error: function test.Foo.opIn_r (int i) is not callable using argument types (string) test.d(25): Error: cannot implicitly convert expression ("") of type string to int which much better than Bar's error message.
Apr 29 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 10:21:19PM +0200, Alex Rřnne Petersen wrote:
 On 29-04-2012 00:49, H. S. Teoh wrote:
On Sun, Apr 29, 2012 at 12:39:03AM +0200, Timon Gehr wrote:


- 'in' operator returning a pointer to the element.

Yeah that one elicited a WAT from me when I first started using it. Surprisingly enough, it sounded OK when I read it in TDPL, but when I started using it I realized just how b0rken it is.


 
 How so? It's seemed entirely reasonable to me.

I was expecting it to return bool. It also precludes bool-valued AA's from being implemented using bit arrays, since you can't return a pointer to a bit. T -- In order to understand recursion you must first understand recursion.
Apr 29 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/28/12, Walter Bright <newshound2 digitalmars.com> wrote:
 A mixin template is instantiated in context of the instantiation point,
 while a
 regular template is instantiated in the context of the template definition
 point.

Ooooh. Suddenly that explains some of my compilation errors.
Apr 28 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 11:47:31AM -0700, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question.
 The idea was which features in D are redundant and/or do not add
 significant value?
 
 A couple already agreed upon ones are typedef and the cfloat,
 cdouble and creal types.

D has typedef?? Wow. And I thought I had a good grasp of D.
 What's your list?

Comma operator. foreach_reverse. with statements. They make code hard to read, and besides you can (or should be able to) alias long expressions into a short identifier for this purpose anyway. The great variety of string quoting syntax, while useful, seem to need some cleanup and unification. Get rid of r"", `` works just fine. (Or vice versa, but not both.) Delimited strings and token strings may be possible to be unified, perhaps? It's about time octal literals went the way of the bit bucket. There's probably more, I'll post them as I think of them. T -- Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.
Apr 28 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 28-04-2012 22:43, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 11:47:31AM -0700, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question.
 The idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat,
 cdouble and creal types.

D has typedef?? Wow. And I thought I had a good grasp of D.

It "has" typedef, but it is deprecated.
 What's your list?

Comma operator.

+1.
 foreach_reverse.

+1.
 with statements. They make code hard to read, and besides you can (or
 should be able to) alias long expressions into a short identifier for
 this purpose anyway.

I don't think I agree entirely here. If you have very long sequences of statements operating on the same object, with can be very useful. That said, I recognize that the current implementation of with needs some work.
 The great variety of string quoting syntax, while useful, seem to need
 some cleanup and unification. Get rid of r"", `` works just fine. (Or
 vice versa, but not both.) Delimited strings and token strings may be
 possible to be unified, perhaps?

IMHO r"" is better than `` for the simple reason that typing `` is extremely annoying on non-US keyboards.
 It's about time octal literals went the way of the bit bucket.

I think those are already deprecated.
 There's probably more, I'll post them as I think of them.


 T

-- - Alex
Apr 29 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-29 22:26, Alex Rřnne Petersen wrote:

 IMHO r"" is better than `` for the simple reason that typing `` is
 extremely annoying on non-US keyboards.

`` is better because you don't have to escape ". -- /Jacob Carlborg
Apr 30 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 30-04-2012 09:08, Jacob Carlborg wrote:
 On 2012-04-29 22:26, Alex Rřnne Petersen wrote:

 IMHO r"" is better than `` for the simple reason that typing `` is
 extremely annoying on non-US keyboards.

`` is better because you don't have to escape ".

That only applies when you actually have " in the string. I think both have their uses. -- - Alex
Apr 30 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-30 17:14, Alex Rřnne Petersen wrote:
 On 30-04-2012 09:08, Jacob Carlborg wrote:
 On 2012-04-29 22:26, Alex Rřnne Petersen wrote:

 IMHO r"" is better than `` for the simple reason that typing `` is
 extremely annoying on non-US keyboards.

`` is better because you don't have to escape ".

That only applies when you actually have " in the string. I think both have their uses.

When is r"" a better use than ``? We already have the regular "". -- /Jacob Carlborg
Apr 30 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 30-04-2012 21:42, Jacob Carlborg wrote:
 On 2012-04-30 17:14, Alex Rřnne Petersen wrote:
 On 30-04-2012 09:08, Jacob Carlborg wrote:
 On 2012-04-29 22:26, Alex Rřnne Petersen wrote:

 IMHO r"" is better than `` for the simple reason that typing `` is
 extremely annoying on non-US keyboards.

`` is better because you don't have to escape ".

That only applies when you actually have " in the string. I think both have their uses.

When is r"" a better use than ``? We already have the regular "".

You don't have escape sequences inside r"", so they can be useful if you have backslashes in your string. -- - Alex
Apr 30 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-30 22:03, Alex Rřnne Petersen wrote:
 On 30-04-2012 21:42, Jacob Carlborg wrote:

 When is r"" a better use than ``? We already have the regular "".

You don't have escape sequences inside r"", so they can be useful if you have backslashes in your string.

`` can be used for that. ` is good because it's a different delimiter compared to r"" or "". -- /Jacob Carlborg
May 01 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 01-05-2012 13:22, Jacob Carlborg wrote:
 On 2012-04-30 22:03, Alex Rřnne Petersen wrote:
 On 30-04-2012 21:42, Jacob Carlborg wrote:

 When is r"" a better use than ``? We already have the regular "".

You don't have escape sequences inside r"", so they can be useful if you have backslashes in your string.

`` can be used for that. ` is good because it's a different delimiter compared to r"" or "".

It *can*, but it's annoying on non-US keyboards, which was my original point. -- - Alex
May 01 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-01 16:28, Alex Rřnne Petersen wrote:

 It *can*, but it's annoying on non-US keyboards, which was my original
 point.

Well, I don't agree. -- /Jacob Carlborg
May 01 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 30-04-2012 19:05, H. S. Teoh wrote:
 On Mon, Apr 30, 2012 at 06:54:31PM +0200, bearophile wrote:
 H. S. Teoh:

 Which means your code is at the mercy of the external library.
 Upstream updates a class, and suddenly a whole bunch of code is
 unnecessarily broken

How? (I think you are wrong again).

struct S { int x; } void main() { int y; S s; with(s) { x = 1; y = 2; } } This works. Now suppose S is updated to: struct S { int x; int y; } Now the program fails to compile because S.y conflicts with the local y. This is bad because unrelated code is broken just by changing S: it breaks encapsulation. This is just a small example; imagine if a lot of code uses S. Many places may break when S changes just because they happen to use the wrong local variable names. Whereas if you had _not_ used with, this is a non-problem, since you'd be referring to s.x, and the fact that S now has a new member does not break any existing code regardless of how it was named. T

You always risk breaking *something* when you change an interface, whether it's through adding or removing members. The problem you point out is not at all specific to with. Consider UFCS: You have struct S and free function foo operating on S. Upstream now adds a method foo to S. -- - Alex
Apr 30 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 05:35 PM, H. S. Teoh wrote:
 On Mon, Apr 30, 2012 at 10:21:23AM +0200, bearophile wrote:
 H. S. Teoh:

 I think the correct solution here is to use alias. (If that doesn't
 work, then it should be made to work. It's a lot cleaner and doesn't
 introduce potentially nasty ambiguities into code,

What ambiguities?

When you have nested with's. Or when the object members shadow local variables in the parent scope. struct S { int x; } void main() { int x, y; S s; with(s) { x = 1; y = 2; } } [snip.]

You probably should try compiling that code. ;)
Apr 30 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 07:05 PM, H. S. Teoh wrote:
 On Mon, Apr 30, 2012 at 06:54:31PM +0200, bearophile wrote:
 H. S. Teoh:

 Which means your code is at the mercy of the external library.
 Upstream updates a class, and suddenly a whole bunch of code is
 unnecessarily broken

How? (I think you are wrong again).

struct S { int x; } void main() { int y; S s; with(s) { x = 1; y = 2; } } This works. Now suppose S is updated to: struct S { int x; int y; } Now the program fails to compile because S.y conflicts with the local y. This is bad because unrelated code

It is not unrelated.
 is broken just by changing S: it breaks encapsulation.

No it does not. Changing an interface is bound to break code.
 This is just a small example; imagine if a lot of
 code uses S. Many places may break when S changes just because they
 happen to use the wrong local variable names.

That is an extremely constructed argument. I cannot imagine that this will ever be a problem in practice.
 Whereas if you had _not_ used with, this is a non-problem, since you'd
 be referring to s.x, and the fact that S now has a new member does not
 break any existing code regardless of how it was named.

int* x = cast(int*)&s; int y = *x; S t = *cast(S*)&y; static if(!is(typeof(S.y)){ ... }
Apr 30 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was which features in D are redundant and/or 
 do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble and creal types.

 What's your list?

I guess the underlying problem is inability to formulate the target state of the language with specified relations between different components. Being looking at the language since late 2011 I found problematic to know the language as a whole. When a newcomer looks for information he either gets a common overview "native efficiency, ..." at dlang.org with (outdated) documentation or videos on youtube which explains how scope(xxx) beats exceptions and templates are superior to that in C++ and similar posts in the web, let alone toolchain lack complaints. My comment was provoked mainly by http://forum.dlang.org/thread/vwpzirpppabcgylmvpsx forum.dlang.org discussion (D3 idea). You ask which features are redundant or not significant, but this depends on how features are integrated in the rest of language and without clear and completed vision there is no answer. And please remember, that each of D member has its own (biased) information about D and what to do. The language is moving and it is hard to reveal how any change will affect other components. Even if you found a particular item redundant there is no guarantee that the situation will not change in future. Currently I (who looked for a language that combines C# "usability" and C performance) view D as a ship which sails in unknown direction with lots of holes (look at bugzilla proposals how to make a language) and what I found the most dreaded is that the direction of the ship movement today is determined by which hole was fixed yesterday. So, you are free to ask ship's crew about what hole and how to fix and expect that it will tomorrow bring ship to a better place, but without final destination this brownian movement may theoretically last infinitely, but of course, in practice it will lead either to ship crashing, departure of sailors or finally targeting an unexpected place with unsatisfactory result.
Apr 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
[...]
 - AAs integrated in the language; you barely ever use AA literals and
 having them purely in Phobos would help get rid of the runtime fat, as
 well as better implementations

On the contrary, AA's are a major reason I started programming in D. In this day and age, it's simply inexcusable to *not* have some kind of hash type available by default.
 - Phobos is too fat - it needs to shrink to just a few core modules,
 others being distributed via some system like CPAN for Perl

Um... that's what a *library* is supposed to be: a large collection of useful stuff from which you can pick the few that you need right now.
 - Properties - they're kinda broken at this point and the value is
 questionable

What kind of properties are you referring to?
 -  trusted  system

These are necessary.
 - Exception handling - a lot of runtime, questionable value

I completely disagree. No exception handling means lots and lots and lots of boilerplate code for checking error codes, return values, which are too tedious to write, which translates to many people leaving them out and ending up with unreliable code that fail silently or crash outright when a function call they assumed would work stopped working. If you've worked in large multi-person projects, you'll see very quickly why you *need* exception handling. No modern language can do without exception handling. Maybe you have a beef with how it's currently done in D, but regardless, you *need* exception handling of some kind.
 - Versions - not redundant, but needs a better system (with AND/OR,
 possibility of de-versioning, the assignment op to set versions is
 kinda bad)

I find versions sorta neat... and they're simple enough that they don't add to much bloat to the language. (Whereas if you added AND and OR to them, then they start duplicating the function of static if, and that's when they become redundant.) T -- Your inconsistency is the only consistent thing about you! -- KD
Apr 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 10:08:29PM +0200, SomeDude wrote:
 On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:

So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?

Sorry, with that, I agree. Nick Sabalausky proposed to remove version entirely. But I agree there could be something like: version(LINUX|OSX){ ... } else { ... }

But if you're gonna do that, might as well just fold the feature into static if. The point of having a separate version construct was to provide a very basic, simple, easy-to-implement and easy-to-use way of versioning stuff. I don't think it was ever intended to be a full-fledged versioning system. T -- What doesn't kill me makes me stranger.
Apr 28 2012
prev sibling next sibling parent "D Day" <damianday hotmail.co.uk> writes:
On Saturday, 28 April 2012 at 20:49:33 UTC, Maxim Fomin wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was which features in D are redundant 
 and/or do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble and creal types.

 What's your list?

I guess the underlying problem is inability to formulate the target state of the language with specified relations between different components. Being looking at the language since late 2011 I found problematic to know the language as a whole. When a newcomer looks for information he either gets a common overview "native efficiency, ..." at dlang.org with (outdated) documentation or videos on youtube which explains how scope(xxx) beats exceptions and templates are superior to that in C++ and similar posts in the web, let alone toolchain lack complaints. My comment was provoked mainly by http://forum.dlang.org/thread/vwpzirpppabcgylmvpsx forum.dlang.org discussion (D3 idea). You ask which features are redundant or not significant, but this depends on how features are integrated in the rest of language and without clear and completed vision there is no answer. And please remember, that each of D member has its own (biased) information about D and what to do. The language is moving and it is hard to reveal how any change will affect other components. Even if you found a particular item redundant there is no guarantee that the situation will not change in future. Currently I (who looked for a language that combines C# "usability" and C performance) view D as a ship which sails in unknown direction with lots of holes (look at bugzilla proposals how to make a language) and what I found the most dreaded is that the direction of the ship movement today is determined by which hole was fixed yesterday. So, you are free to ask ship's crew about what hole and how to fix and expect that it will tomorrow bring ship to a better place, but without final destination this brownian movement may theoretically last infinitely, but of course, in practice it will lead either to ship crashing, departure of sailors or finally targeting an unexpected place with unsatisfactory result.

Apr 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 09:58:02PM +0200, foobar wrote:
[...]
 D has a lot of ad-hock features which make the language
 needlessly large and complex. I'd strive to replace these with
 better general purpose mechanisms.
 
 My list:
 * I'd start with getting rid of foreach completely. (not just
 foreach_reverse). This is nothing more than a fancy function with
 a delegate parameter.

I disagree. Having a dedicated foreach construct allows the compiler to optimize away the delegate in certain cases. I wouldn't want to incur the cost of creating and passing a delegate in something as simple as foreach (i; 0..100), for example.
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

Actually, I rather like the enum idiom of declaring compile-time constants. Though it could do with a renaming to something more befitting.
 * version - this does not belong in a programming language. Git
 is a much better solution.

This is an interesting idea. But using separate git branches just for having versioned code seems a bit like total overkill... plus a maintenance nightmare since you have to continue pull and merge changes to every porting branch every time development happens. Whereas having everything represented in source means that whoever writes a new feature is also responsible for making it work with whatever versions are currently out there. After-the-fact fixes are always painful.
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; Pascal
 units all solved this long ago.

I proposed a while ago that .di files should be replaced by something better: omit ALL function bodies, template bodies, private members, etc., and just keep the "real" public API in the human-readable part of the file. Function and template bodies should be kept in as a binary blob readable by the compiler (which obviously needs to know them otherwise it won't be able to expand templates). (Yes the binary blob can be reverse-engineered, but so can executables, so it's a moot point. We're not trying to write cryptographic security here, but it's nice to separate what the compiler needs to know vs. what the user of a library needs to know.)
 * This is a big one: get rid of *all* current compile time
 special syntax. It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons. This
 would reduce the size of the language to half of its current
 size, maybe even more.

I have to disagree here. CTFE and compile-time features is a major reason I like D. I argue rather that compile-time features should be *improved*. The current situation is good, but not quite there yet. It can be made better. T -- Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.
Apr 28 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 20:49:33 UTC, Maxim Fomin wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was which features in D are redundant 
 and/or do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble and creal types.

 What's your list?

I guess the underlying problem is inability to formulate the target state of the language with specified relations between different components. Being looking at the language since late 2011 I found problematic to know the language as a whole. When a newcomer looks for information he either gets a common overview "native efficiency, ..." at dlang.org with (outdated) documentation or videos on youtube which explains how scope(xxx) beats exceptions and templates are superior to that in C++ and similar posts in the web, let alone toolchain lack complaints. My comment was provoked mainly by http://forum.dlang.org/thread/vwpzirpppabcgylmvpsx forum.dlang.org discussion (D3 idea). You ask which features are redundant or not significant, but this depends on how features are integrated in the rest of language and without clear and completed vision there is no answer. And please remember, that each of D member has its own (biased) information about D and what to do. The language is moving and it is hard to reveal how any change will affect other components. Even if you found a particular item redundant there is no guarantee that the situation will not change in future. Currently I (who looked for a language that combines C# "usability" and C performance) view D as a ship which sails in unknown direction with lots of holes (look at bugzilla proposals how to make a language) and what I found the most dreaded is that the direction of the ship movement today is determined by which hole was fixed yesterday. So, you are free to ask ship's crew about what hole and how to fix and expect that it will tomorrow bring ship to a better place, but without final destination this brownian movement may theoretically last infinitely, but of course, in practice it will lead either to ship crashing, departure of sailors or finally targeting an unexpected place with unsatisfactory result.

That's a very well worded post. That's one more reason why the most important thing imho is to have the current feature set stabilized, and not adding or removing features every other month, because we don't have enough experience with D to be certain such feature is redundant. This kind of experience can only be gained with feedback from hundreds or thousands of users, and there aren't that many users in this newsgroup. D is large enough that I'm pretty sure no two programmers use the same features. That's why we have so different answers to the question "which features is useless ?". Yet every programmer has his favorite feature that saves his ass at one point or another, and that's why everybody finds it's a joy to use. Were it missing, someone would complain. I'm pretty confident that in a sufficiently large program, nearly every single feature of the language will be put to good use. Now what people don't like is when features or Phobos don't work as expected, I suppose that's what you call holes. And that's another matter. I've browsed through hundreds of bug reports last week, and I could see many many features don't work as expected. And that's the most important problem in my opinion. That's where most of the efforts should be put.
Apr 28 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
 [...]
 - AAs integrated in the language; you barely ever use AA 
 literals and
 having them purely in Phobos would help get rid of the runtime 
 fat, as
 well as better implementations

On the contrary, AA's are a major reason I started programming in D. In this day and age, it's simply inexcusable to *not* have some kind of hash type available by default.

Besides AA literals, library can handle this JUST FINE.
 - Phobos is too fat - it needs to shrink to just a few core 
 modules,
 others being distributed via some system like CPAN for Perl

Um... that's what a *library* is supposed to be: a large collection of useful stuff from which you can pick the few that you need right now.

Too large collection becomes too hard to manage. Separating it and distributing in style "you pay for what you use" is IMO the right approach.
 - Properties - they're kinda broken at this point and the 
 value is
 questionable

What kind of properties are you referring to?

The property crap. It's broken. If anything, it needs something like in C#.
 -  trusted  system

These are necessary.

They're far from necessary.
 - Exception handling - a lot of runtime, questionable value

I completely disagree. No exception handling means lots and lots and lots of boilerplate code for checking error codes, return values, which are too tedious to write, which translates to many people leaving them out and ending up with unreliable code that fail silently or crash outright when a function call they assumed would work stopped working. If you've worked in large multi-person projects, you'll see very quickly why you *need* exception handling. No modern language can do without exception handling. Maybe you have a beef with how it's currently done in D, but regardless, you *need* exception handling of some kind.

The exception handling system via try/catch is as bad and tedious as error codes, except the added runtime. It all roots from the idea "catch everything that throws". This is broken, as you DON'T always need to handle all sorts of errors (letting it segfault or something sometimes simply proves to be better than trying to save the situation; or you can simply assert it). Also http://yosefk.com/c++fqa/exceptions.html#fqa-17.1
 - Versions - not redundant, but needs a better system (with 
 AND/OR,
 possibility of de-versioning, the assignment op to set 
 versions is
 kinda bad)

I find versions sorta neat... and they're simple enough that they don't add to much bloat to the language. (Whereas if you added AND and OR to them, then they start duplicating the function of static if, and that's when they become redundant.)

They're nearly unusable now. And the syntax simply makes no sense.
 T

Apr 28 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 21:05:12 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
 [...]
 - AAs integrated in the language; you barely ever use AA 
 literals and
 having them purely in Phobos would help get rid of the 
 runtime fat, as
 well as better implementations

On the contrary, AA's are a major reason I started programming in D. In this day and age, it's simply inexcusable to *not* have some kind of hash type available by default.

Besides AA literals, library can handle this JUST FINE.

Yeah, but core language AA are so useful it would be a MAJOR mistake to remove them. In Python too, you could put the AA in the libraries. Yet everybody uses the AA that are in the language. Where I DO agree with you is, Phobos should be a two level library, i.e a minimalistic library, with about the same feature set as the standard C library + multithreading, and a superset with the full range of features (ranges, algorithms, etc). I've already advocated it somewhere else.
Apr 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 10:07:54PM +0200, q66 wrote:
 On Saturday, 28 April 2012 at 20:04:11 UTC, Walter Bright wrote:
On 4/28/2012 1:00 PM, bearophile wrote:
"Phobos is too fat"

As opposed to Phobos being phat?

Well my concern is so that it doesn't end up like Python standard library, half-bitrotting and half-crap :) Huge standard library is not a good idea even for a very big language/library team, and D doesn't have one.

On the contrary, being able to do stuff without having to reinvent the square wheel every single time is a big plus. I used to have a strong NIH attitude -- years ago during my DOS days, I reimplemented video output routines in assembly because I wanted to use protected mode in DOS. Nothing in the C standard library worked because they are all tied to DOS or otherwise do stuff that breaks in protected mode. So I reinvented file abstractions, string processing, etc., in my own library. I was rather proud of it too: my video routines took advantage of features of my particular chosen video mode, so I could use the i386's built-in loop instructions and other such things to output characters really fast. In retrospect, it was a fun and very educational experience. But to be frank, you can only reinvent the C standard library so many times before you get totally sick and tired of it. I mean, I've implemented linked lists, hand-made lexers, parsers, etc., who knows how many times, and nowadays the thought of having to do it all over again just makes me feel, "I should be doing better things with my time". The whole point of a standard library is that if somebody has written that code before, and it's general enough for everyday use, then you shouldn't need to download this, install that, configure the other, before you can use it. It's a major plus if you're publishing code to be able to say, just download my sources and compile it with the language standard library and it will all work. As opposed to, if you want to compile my code, you need library X and Y which depend on W and Z, all of which have to be downloaded from different places all over the 'net and you better make sure you get the right versions otherwise everything will break. Besides, the whole point of a library is that only what you need is actually linked in. You don't walk around carrying every book from your bookshelf just because you *might* need to refer to one of them on some rare occasion. But the library itself doesn't need to be minimal, in fact, rather to the contrary. (That's why it's called a "library".) T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy
Apr 28 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 What's your list?

I think most the responses to this thread are insane. But, there is one thing I don't think D needs: new. I'm pretty sure it could be done in the library now that we have robust templates, which I think would open up some nice things. Suppose: module std.typecons; NotNull!T new(T, Args...)(Args args) { return assumeNotNull(core.gc.new!T(args)); } module core.gc; T new(T, Args...)(Args args) { // implement the new we know now } And so on, then you could get new allocators just by changing which module you import new from. We could kinda sorta do it now, but it wouldn't be as consistent, and of course, the name "new" is unavailable.
Apr 28 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 28-04-2012 23:20, Adam D. Ruppe wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 What's your list?

I think most the responses to this thread are insane. But, there is one thing I don't think D needs: new. I'm pretty sure it could be done in the library now that we have robust templates, which I think would open up some nice things. Suppose: module std.typecons; NotNull!T new(T, Args...)(Args args) { return assumeNotNull(core.gc.new!T(args)); } module core.gc; T new(T, Args...)(Args args) { // implement the new we know now } And so on, then you could get new allocators just by changing which module you import new from. We could kinda sorta do it now, but it wouldn't be as consistent, and of course, the name "new" is unavailable.

OK, so while in general I agree that 'new' shouldn't be tied to the GC by default, I don't think your example of swapping allocators through imports is a good idea at all. The reason is simple: More often than not, it never *is* as simple as just changing an import. Some allocators use stack allocation, some use C heap allocation, some use the druntime GC, some use the libgc library, ... All of these need different treatment of the allocated memory, so I don't think there is much to be gained here. -- - Alex
Apr 29 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Saturday, 28 April 2012 at 21:19:00 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 10:07:54PM +0200, q66 wrote:
 On Saturday, 28 April 2012 at 20:04:11 UTC, Walter Bright 
 wrote:
On 4/28/2012 1:00 PM, bearophile wrote:
"Phobos is too fat"

As opposed to Phobos being phat?

Well my concern is so that it doesn't end up like Python standard library, half-bitrotting and half-crap :) Huge standard library is not a good idea even for a very big language/library team, and D doesn't have one.

On the contrary, being able to do stuff without having to reinvent the square wheel every single time is a big plus. I used to have a strong NIH attitude -- years ago during my DOS days, I reimplemented video output routines in assembly because I wanted to use protected mode in DOS. Nothing in the C standard library worked because they are all tied to DOS or otherwise do stuff that breaks in protected mode. So I reinvented file abstractions, string processing, etc., in my own library. I was rather proud of it too: my video routines took advantage of features of my particular chosen video mode, so I could use the i386's built-in loop instructions and other such things to output characters really fast. In retrospect, it was a fun and very educational experience. But to be frank, you can only reinvent the C standard library so many times before you get totally sick and tired of it. I mean, I've implemented linked lists, hand-made lexers, parsers, etc., who knows how many times, and nowadays the thought of having to do it all over again just makes me feel, "I should be doing better things with my time". The whole point of a standard library is that if somebody has written that code before, and it's general enough for everyday use, then you shouldn't need to download this, install that, configure the other, before you can use it. It's a major plus if you're publishing code to be able to say, just download my sources and compile it with the language standard library and it will all work. As opposed to, if you want to compile my code, you need library X and Y which depend on W and Z, all of which have to be downloaded from different places all over the 'net and you better make sure you get the right versions otherwise everything will break. Besides, the whole point of a library is that only what you need is actually linked in. You don't walk around carrying every book from your bookshelf just because you *might* need to refer to one of them on some rare occasion. But the library itself doesn't need to be minimal, in fact, rather to the contrary. (That's why it's called a "library".) T

Well I'm not obviously saying the features should disappear, what I had in mind was some kind of distribution system for small packages, kinda like luaforge or CPAN, where everyone could find what they need for their project. But keep Phobos itself small.
Apr 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 11:21:52PM +0200, q66 wrote:
[...]
 Well I'm not obviously saying the features should disappear, what I
 had in mind was some kind of distribution system for small packages,
 kinda like luaforge or CPAN, where everyone could find what they need
 for their project. But keep Phobos itself small.

If you're talking about very specific, niche features (like parsing protein structure data files), then I agree they should be distributed in separate libraries. But generic stuff that can be used in a wide array of tasks should go in the standard library. Again I say, being able to distribute your sources without requiring the user to download 50 different libraries just to compile it, is a big plus to me. Being able to say "just compile with the standard library" is best, because it means people can just download my code and compile it immediately. Same goes for binary distribution: it's much much better to say "here, just download this binary and run it with the language standard library" than to say "download this binary, then library X, then library Y, then library Z which is needed by library X, then library W needed by ...". T -- Freedom of speech: the whole world has no right *not* to hear my spouting off!
Apr 28 2012
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was which features in D are redundant and/or 
 do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble and creal types.

 What's your list?

Here's my list: - Properties. They add no value and just start pointless discussions about what should and shouldn't be a property. - UFCS. It's just sugar, but adds complexity. - const/immutable/inout/shared/pure. These add massive complexity to the language for little (IMO) benefit. When I do multi-threading, I usually have to resort to casting. Maybe these will improve with time. - opDispatch. I think it just promotes sloppy, obfuscated code for minor syntactical benefit. Member access through pointers should require -> like in C++ so that you can overload it for smart pointer/reference ADTs. That's all I can think of for now.
Apr 28 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/28/2012 11:42 PM, Peter Alexander wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

Here's my list: - Properties. They add no value and just start pointless discussions about what should and shouldn't be a property. - UFCS. It's just sugar, but adds complexity. - const/immutable/inout/shared/pure. These add massive complexity to the language for little (IMO) benefit. When I do multi-threading, I usually have to resort to casting. Maybe these will improve with time. - opDispatch. I think it just promotes sloppy, obfuscated code for minor syntactical benefit. Member access through pointers should require -> like in C++ so that you can overload it for smart pointer/reference ADTs. That's all I can think of for now.

- UFCS: The complexity comes from having multiple function invocation syntaxes. UFCS actually makes that situation better without adding a lot of complexity to the compiler implementation. - const/immutable/shared/pure shared: The fact that everything that is not marked as shared is actually thread-local is extremely important. I think most other imperative languages got this wrong. But if shared is explicit in the type system, immutable really should be explicit too. The sad part is that the qualifiers don't play nicely with reference types at the moment. - opDispatch This is useful and of significant value if used the right way. I hope you are not actually serious about that '->' part.
Apr 28 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Peter Alexander" <peter.alexander.au gmail.com> wrote in message 
news:nvvuxboigxxfdqfhyftw forum.dlang.org...
 To be honest, I don't like the idea of member functions at all. Having two 
 syntaxes for calling a function is the core problem, and UFCS is just an 
 extra complication on top of it to try and mitigate the original problem.

 f(x) ---> x.f() is not progress in language design.

 I'm serious. I don't like overloaded syntax.  foo.bar shouldn't also mean 
 (*foo).bar -- it causes confusion and introduces ambiguities when either 
 could work. Combine this with opDispatch, UFCS and function overloading 
 and your in for some nasty headaches.

 Glancing at that code, it looks like foo has two member variables. It is 
 also not clear that each access involves a hash-table lookup.

It sounds like you just simply don't like abstractions. I can understand that (although I don't agree with it), but it always puzzles me why such people even try to use high-level langauges at all instead of just binary machine code. And for the record, I've *never* seen anyone confused by foo.bar syntax being used on reference types.
Apr 29 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-28 23:42, Peter Alexander wrote:

 Here's my list:

 - Properties. They add no value and just start pointless discussions
 about what should and shouldn't be a property.

 - UFCS. It's just sugar, but adds complexity.

 - const/immutable/inout/shared/pure. These add massive complexity to the
 language for little (IMO) benefit. When I do multi-threading, I usually
 have to resort to casting. Maybe these will improve with time.

 - opDispatch. I think it just promotes sloppy, obfuscated code for minor
 syntactical benefit. Member access through pointers should require ->
 like in C++ so that you can overload it for smart pointer/reference ADTs.

 That's all I can think of for now.

I love all these features beside the attributes. -- /Jacob Carlborg
Apr 29 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 28-04-2012 23:59, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 11:42:31PM +0200, Peter Alexander wrote:
 [...]
 - UFCS. It's just sugar, but adds complexity.

On the contrary, it's a major helper for writing generic code. In my new AA implementation, I use UFCS to provide a default toHash function for all types that don't already provide one. Without UFCS, this would require lots of ugly hacks and constraints on how user code can provide custom hash functions. (Due to the way D overloading works, UFCS is currently the only way to provide a default function without causing a conflict at compile-time.)
 - const/immutable/inout/shared/pure. These add massive complexity to
 the language for little (IMO) benefit. When I do multi-threading, I
 usually have to resort to casting. Maybe these will improve with
 time.

Yeah they are complex, but they also open ways for powerful optimizations by the compiler.

I don't know of any production compilers that make significant use of such annotations in any language. These qualifiers look nice in theory, but have little practical value other than making it easier to reason about code. I don't think they should go away, just sayin'. (BTW, I think nothing is wrong with pure.)
 Though I do have to say that inout needs some serious reconsideration,
 since the way they work currently is ambiguous when you have more than
 one inout argument, or when you have a delegate parameter with inout
 arguments.


 - opDispatch. I think it just promotes sloppy, obfuscated code for
 minor syntactical benefit.

Wrong. It's a powerful tool for building runtime dynamic class loading. It allows you to write generic code that Just Works without having to special-case them for statically-known classes vs. dynamic classes. If anything, I'd argue for *more* similar features that let you write generic code that integrates seamlessly into the language. Just because it's been used (arguably abused) for things like making roman numerals or vector swizzling, doesn't mean it's a bad feature.
 Member access through pointers should require ->  like in C++ so that
 you can overload it for smart pointer/reference ADTs.

Yikes!! Please don't reintroduce that monstrous -> operator from C++! (Besides, most of the time idiomatic D code doesn't even need pointers.) T

-- - Alex
Apr 29 2012
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 01:41, Peter Alexander wrote:
 On Saturday, 28 April 2012 at 23:29:35 UTC, bearophile wrote:
 Peter Alexander:

 f(x) ---> x.f() is not progress in language design.

I used to think the same. But Haskell offers "." and $ to chain functions and remove parentheses, F# has the |> pipe operator. In D UCFS is almost equally useful to turn nesting of function calls in a more readable chain. In functional-style code this makes a lot of difference, turning: foo(bar(copy(baz(a), spam(b)))) Into: baz(a).copy(b.spam()).bar().foo() When I see 3+ nested parentheses I find it hard to read the expression. While a chain is easy to read.

What D does and what Haskell does are very different things. D has (at least) two types of functions: free functions and member functions. UFCS makes free functions look like member functions. In Haskell, $ just gives you a way of re-ordering precedence -- it doesn't hide anything. This matters because UFCS in D is deceitful. It makes you think the free function is a member function when it is not. struct Foo { void bar() {} } void baz(Foo f) {} Foo f; f.bar(); // ok f.baz(); // ok, looks like baz is a member function auto pbar = &Foo.bar; // ok auto pbaz = &Foo.baz; // error! IMO, D would be better with Haskell's function calling syntax (of course, this would require many, many other syntactical changes).
 But in D the main purpose of "pure" is not as optimization tool, but
 more as a tool to enforce a better coding style, that makes code
 understanding (and testing simpler), and helps avoid some bugs, coming
 from using variables from outer scopes.

True, but I'm quite happy to write pure functions without the static checking. I do not believe that the safety provided by the static checks outweighs the development cost of ensuring you have the correct qualifiers everywhere.

In my experience, pure is only hard to use in D due to the runtime and standard library not being properly annotated. I don't think anything is wrong with the language feature itself. -- - Alex
Apr 29 2012
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 00:30, Manu wrote:
 On 29 April 2012 00:42, Peter Alexander <peter.alexander.au gmail.com
 <mailto:peter.alexander.au gmail.com>> wrote:

     On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:

         Andrei and I had a fun discussion last night about this
         question. The idea was which features in D are redundant and/or
         do not add significant value?

         A couple already agreed upon ones are typedef and the cfloat,
         cdouble and creal types.

         What's your list?


     Here's my list:

     - Properties. They add no value and just start pointless discussions
     about what should and shouldn't be a property.

     - UFCS. It's just sugar, but adds complexity.

     - const/immutable/inout/shared/__pure. These add massive complexity
     to the language for little (IMO) benefit. When I do multi-threading,
     I usually have to resort to casting. Maybe these will improve with time.

     - opDispatch. I think it just promotes sloppy, obfuscated code for
     minor syntactical benefit. Member access through pointers should
     require -> like in C++ so that you can overload it for smart
     pointer/reference ADTs.

     That's all I can think of for now.


 I disagree with every one of those points, except maybe 'shared', which
 seems like a good idea in theory, but I think it's completely broken
 (every interaction requires an explicit cast, and there is no facility
 for transfer of ownership, which is a VERY common operation in my
 experience)

For shared to be useful, every function you call on/with a shared object/value must be templatized. This may be nice if most of the code you write is template-rich, but like anything else, templates are not a silver bullet. IMHO shared is heavily biased in its design, which is bad. -- - Alex
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 20:51:54 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 10:08:29PM +0200, SomeDude wrote:
 On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:

So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?

Sorry, with that, I agree. Nick Sabalausky proposed to remove version entirely. But I agree there could be something like: version(LINUX|OSX){ ... } else { ... }

But if you're gonna do that, might as well just fold the feature into static if. The point of having a separate version construct was to provide a very basic, simple, easy-to-implement and easy-to-use way of versioning stuff. I don't think it was ever intended to be a full-fledged versioning system. T

I really don't care how it's implemented or what its syntax is. What I do want is begin able with a single glimpse, to see the different versions of the code, without having the impression to plunge into a "static if hell" with 5 levels of indentation. Having a different keyword helps for this. Besides, a specific keyword makes parsing code easier.
Apr 28 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 28/04/2012 20:47, Walter Bright a écrit :
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

OK longer answer. - is is messed up. It is a massive hack and have to be rationalized. - version is a bad version of static if. The static if part of the version must go. - comma expression is confusing and have very little benefice. - out arguments. We can return tuples, out argument is going backward in history. - many array properties (.sort for instance) are useless and would be way better as libs.
Apr 28 2012
next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 21:51:42 UTC, deadalnix wrote:
  - out arguments. We can return tuples, out argument is going 
 backward in history.
  - many array properties (.sort for instance) are useless and 
 would be way better as libs.

What happens the day the language is actually fit for embedded programming, and you don't want to have to link against Phobos because it's too big ?
Apr 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 11:57:46PM +0200, SomeDude wrote:
 On Saturday, 28 April 2012 at 21:51:42 UTC, deadalnix wrote:
 - out arguments. We can return tuples, out argument is going
backward in history.
 - many array properties (.sort for instance) are useless and
would be way better as libs.

What happens the day the language is actually fit for embedded programming, and you don't want to have to link against Phobos because it's too big ?

We need to fix things so that using a single feature in Phobos will not pull in the entire library. That's an implementation issue, not a language issue. T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Apr 28 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 29/04/2012 00:04, H. S. Teoh a écrit :
 On Sat, Apr 28, 2012 at 11:58:19PM +0200, deadalnix wrote:
 [...]
   - is is messed up. It is a massive hack and have to be rationalized.

As I said in another thread, the _functionality_ of various is() expressions are very useful and should be kept. But the _syntax_ is completely b0rked and needs some serious redesign.

That is what I meant.
   - version is a bad version of static if. The static if part of the
 version must go.

What's your proposal?

version(foobar) returning a boolean at compile time for instance.
   - comma expression is confusing and have very little benefice.

+1. I say that D3 should drop the comma operator. Esp. when doing so will open up the way for having native syntax for tuples. Needing to resort to Phobos to have a way to name a compiler-supported type is backwards and silly.
   - out arguments. We can return tuples, out argument is going
 backward in history.

Not when there's no way to name tuples without resorting to Phobos (or copy-n-paste Phobos code).

See how both go together. Remove comma expression, get a nice tuple syntax, and then remove out parameter seems a nice way to go.
Apr 28 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 22:04:26 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 11:57:46PM +0200, SomeDude wrote:
 
 What happens the day the language is actually fit for embedded
 programming, and you don't want to have to link against Phobos
 because it's too big ?

We need to fix things so that using a single feature in Phobos will not pull in the entire library. That's an implementation issue, not a language issue. T

It is, but it's actually a very difficult implementation issue. And what I currently see is, many Phobos bugs are simply not corrected, while DMD bugs actually are. It seems that noone but Andrei is working on Phobos. And he is only part time on it. Also, ranges are cool, but they are big. And not everyone wants to have to huge ranges when they can use simpler, and arguably faster arrays. I'm not very satisfied with the current state of Phobos. Being the standard library, it should *work*. Yet it seems to me some things simply don't work at all. The new regex, for instance, I've yet to compile anything with it. The author argues the CTFE is broken, but even the runtime regex doesn't compile. That's not acceptable in a standard library. So before thinking about removing these little features from the core language, thoses issues with Phobos must first be solved.
Apr 28 2012
prev sibling next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"deadalnix" <deadalnix gmail.com> wrote in message 
news:jnhopd$gi3$1 digitalmars.com...
  - out arguments. We can return tuples, out argument is going backward in 
 history.

You can overload on out parameters. You can't overload on return type. So without "out" making an optional output param would be harder to make and uglier to use. That could be even more of a problem if the out param in question is expensive to compute. Also, out is nice when interfacing with C. Returning tuples wouldn't help here. I do agree that maybe we should *prefer* returning tuples over out params (at least once we kill off the useless comma operator and have a concise built-in syntax for tuples), but I don't think tuples are enough to replace out entirely.
Apr 29 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 29/04/2012 21:30, Nick Sabalausky a Ă©crit :
 "deadalnix"<deadalnix gmail.com>  wrote in message
 news:jnhopd$gi3$1 digitalmars.com...
   - out arguments. We can return tuples, out argument is going backward in
 history.

You can overload on out parameters. You can't overload on return type. So without "out" making an optional output param would be harder to make and uglier to use. That could be even more of a problem if the out param in question is expensive to compute.

Good point, but it have many way to work around and shouldn't justify a feature in the core language by itself, especially if, like out parameter, it is a confusing feature.
 Also, out is nice when interfacing with C. Returning tuples wouldn't help
 here.

C don't have out parameters as D have. C have pointer to do kind of out parameters, and D have pointers too, this is a non issue.
Apr 29 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 30/04/2012 04:34, H. S. Teoh a écrit :
 On Sun, Apr 29, 2012 at 11:18:12PM +0200, deadalnix wrote:
 [...]
 C don't have out parameters as D have. C have pointer to do kind of
 out parameters, and D have pointers too, this is a non issue.

I argue that using 'out' vs. a pointer is a good thing, because it clarifies intent. When you see a pointer, it's far from clear whether it's an input parameter, an output parameter, or both. More and more, I'm leaning towards the opinion that all code should reveal intent, preferably in a language-supported way. Unclear intent is what leads to subtle bugs caused by people calling functions with wrong assumptions. (You'd think this should be a non-problem with programmers, who are presumably smart enough to figure things out without being told in the face, but I've seen too much "enterprise" code by now to not be cynical about it.) T

I do agree. However, I don't think this apply in any way to our case. out parameter is a C usage, and it is confusing in C, because, as you mentioned, you don't know if you pass the pointer because it is an out parameter, because you want to avoid copy, because something else . . . The fact that better constructs (ie Tuples) exists in D make it already clear. And if the point is to fix C, it is useless because the whole thing is already confusing in C.
Apr 30 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 30/04/2012 11:17, SomeDude a Ă©crit :
 On Monday, 30 April 2012 at 02:33:35 UTC, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 11:18:12PM +0200, deadalnix wrote:
 [...]
 C don't have out parameters as D have. C have pointer to do kind of
 out parameters, and D have pointers too, this is a non issue.

I argue that using 'out' vs. a pointer is a good thing, because it clarifies intent. When you see a pointer, it's far from clear whether it's an input parameter, an output parameter, or both. More and more, I'm leaning towards the opinion that all code should reveal intent, preferably in a language-supported way. Unclear intent is what leads to subtle bugs caused by people calling functions with wrong assumptions. (You'd think this should be a non-problem with programmers, who are presumably smart enough to figure things out without being told in the face, but I've seen too much "enterprise" code by now to not be cynical about it.) T

Of course, a better way would be to change the meaning of the comma operator to allow a Python-style syntax for return values, i.e something like int, Error foo(char[] input, ref Bar){...} auto res, err = foo(input, bar);

Exactly.
 We would then only allow in and inout parameters. This would be much
 closer to functional style. There would be no longer any need for the
 "in" and "out" keywords.
 If we push a little further, you can also get rid of inout by doing this:

 int, ref Bar foo(char[] input, ref Bar){...}
 auto out, bar = foo(input, bar);

 Every time the compiler sees the same symbol as an input and output
 parameter, it can assume it's an inout parameter. This, of course, would
 break a lot of code.

It isn't a good idea.
Apr 30 2012
prev sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"SomeDude" <lovelydear mailmetrash.com> wrote in message 
news:ajdmseliewbindkkoxxj forum.dlang.org...
 [...]There would be no longer any need for the "in" and "out" 
 keywords.[...]

void foo() in{ ... } out{ ... } body{ ... }
Apr 30 2012
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-04-2012 00:04, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 11:58:19PM +0200, deadalnix wrote:
 [...]
   - is is messed up. It is a massive hack and have to be rationalized.

As I said in another thread, the _functionality_ of various is() expressions are very useful and should be kept. But the _syntax_ is completely b0rked and needs some serious redesign.
   - version is a bad version of static if. The static if part of the
 version must go.

What's your proposal?
   - comma expression is confusing and have very little benefice.

+1. I say that D3 should drop the comma operator. Esp. when doing so will open up the way for having native syntax for tuples. Needing to resort to Phobos to have a way to name a compiler-supported type is backwards and silly.
   - out arguments. We can return tuples, out argument is going
 backward in history.

Not when there's no way to name tuples without resorting to Phobos (or copy-n-paste Phobos code).
   - many array properties (.sort for instance) are useless and would
 be way better as libs.

Yeah, .sort is redundant, and besides shouldn't be an array "property" to begin with. T

Let's not forget .reverse. Why these are properties (and .dup/.idup) is seriously beyond me..... -- - Alex
Apr 29 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 29/04/2012 22:40, Alex Rřnne Petersen a écrit :
 On 29-04-2012 00:04, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 11:58:19PM +0200, deadalnix wrote:
 [...]
 - is is messed up. It is a massive hack and have to be rationalized.

As I said in another thread, the _functionality_ of various is() expressions are very useful and should be kept. But the _syntax_ is completely b0rked and needs some serious redesign.
 - version is a bad version of static if. The static if part of the
 version must go.

What's your proposal?
 - comma expression is confusing and have very little benefice.

+1. I say that D3 should drop the comma operator. Esp. when doing so will open up the way for having native syntax for tuples. Needing to resort to Phobos to have a way to name a compiler-supported type is backwards and silly.
 - out arguments. We can return tuples, out argument is going
 backward in history.

Not when there's no way to name tuples without resorting to Phobos (or copy-n-paste Phobos code).
 - many array properties (.sort for instance) are useless and would
 be way better as libs.

Yeah, .sort is redundant, and besides shouldn't be an array "property" to begin with. T

Let's not forget .reverse. Why these are properties (and .dup/.idup) is seriously beyond me.....

Why they are not provided as lib but by the core language ?
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 10:40:03PM +0200, Alex Rřnne Petersen wrote:
 On 29-04-2012 00:04, H. S. Teoh wrote:

Yeah, .sort is redundant, and besides shouldn't be an array
"property" to begin with.


 Let's not forget .reverse. Why these are properties (and .dup/.idup)
 is seriously beyond me.....

AFAIK, it's a historical accident. These "properties" date from before people decided to distinguish between methods and properties. T -- "A man's wife has more power over him than the state has." -- Ralph Emerson
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 11:18:12PM +0200, deadalnix wrote:
[...]
 C don't have out parameters as D have. C have pointer to do kind of
 out parameters, and D have pointers too, this is a non issue.

I argue that using 'out' vs. a pointer is a good thing, because it clarifies intent. When you see a pointer, it's far from clear whether it's an input parameter, an output parameter, or both. More and more, I'm leaning towards the opinion that all code should reveal intent, preferably in a language-supported way. Unclear intent is what leads to subtle bugs caused by people calling functions with wrong assumptions. (You'd think this should be a non-problem with programmers, who are presumably smart enough to figure things out without being told in the face, but I've seen too much "enterprise" code by now to not be cynical about it.) T -- Heuristics are bug-ridden by definition. If they didn't have bugs, they'd be algorithms.
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 02:33:35 UTC, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 11:18:12PM +0200, deadalnix wrote:
 [...]
 C don't have out parameters as D have. C have pointer to do 
 kind of
 out parameters, and D have pointers too, this is a non issue.

I argue that using 'out' vs. a pointer is a good thing, because it clarifies intent. When you see a pointer, it's far from clear whether it's an input parameter, an output parameter, or both. More and more, I'm leaning towards the opinion that all code should reveal intent, preferably in a language-supported way. Unclear intent is what leads to subtle bugs caused by people calling functions with wrong assumptions. (You'd think this should be a non-problem with programmers, who are presumably smart enough to figure things out without being told in the face, but I've seen too much "enterprise" code by now to not be cynical about it.) T

Of course, a better way would be to change the meaning of the comma operator to allow a Python-style syntax for return values, i.e something like int, Error foo(char[] input, ref Bar){...} auto res, err = foo(input, bar); We would then only allow in and inout parameters. This would be much closer to functional style. There would be no longer any need for the "in" and "out" keywords. If we push a little further, you can also get rid of inout by doing this: int, ref Bar foo(char[] input, ref Bar){...} auto out, bar = foo(input, bar); Every time the compiler sees the same symbol as an input and output parameter, it can assume it's an inout parameter. This, of course, would break a lot of code.
Apr 30 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Sunday, 29 April 2012 at 19:30:24 UTC, Nick Sabalausky wrote:
 "deadalnix" <deadalnix gmail.com> wrote in message
 news:jnhopd$gi3$1 digitalmars.com...
  - out arguments. We can return tuples, out argument is going 
 backward in history.

You can overload on out parameters. You can't overload on return type. So without "out" making an optional output param would be harder to make and uglier to use. That could be even more of a problem if the out param in question is expensive to compute. Also, out is nice when interfacing with C. Returning tuples wouldn't help here. I do agree that maybe we should *prefer* returning tuples over out params (at least once we kill off the useless comma operator and have a concise built-in syntax for tuples), but I don't think tuples are enough to replace out entirely.

Well the functional way would be to use Option types as in: Tuple!(int, Option!ExpensiveType) foobar(bool cond) { if (cond) return tuple(0, newExpensiveType()); else return tuple(-1, Option.None); } I prefer the above as it's more readable IMO (we REALLY should get a much better tuple syntax though ....) I do agree that this won't work when interfacing with C but IMO we shouldn't design D around limitations of C.
Apr 30 2012
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 18:32:36 UTC, Nick Sabalausky wrote:
 "SomeDude" <lovelydear mailmetrash.com> wrote in message
 news:ajdmseliewbindkkoxxj forum.dlang.org...
 [...]There would be no longer any need for the "in" and "out" 
 keywords.[...]

void foo() in{ ... } out{ ... } body{ ... }

OKay, I meant in the function signatures
Apr 30 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 28/04/2012 20:47, Walter Bright a écrit :
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

Ho god D is HUGE ! OK a last one, synchronized on objects. Most of them are not even shared so it is useless, and is is bad separation of concerns between OOP and multithreading. If you want a mutex, declaring it explicitly is the best option.
Apr 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 11:42:31PM +0200, Peter Alexander wrote:
[...]
 - UFCS. It's just sugar, but adds complexity.

On the contrary, it's a major helper for writing generic code. In my new AA implementation, I use UFCS to provide a default toHash function for all types that don't already provide one. Without UFCS, this would require lots of ugly hacks and constraints on how user code can provide custom hash functions. (Due to the way D overloading works, UFCS is currently the only way to provide a default function without causing a conflict at compile-time.)
 - const/immutable/inout/shared/pure. These add massive complexity to
 the language for little (IMO) benefit. When I do multi-threading, I
 usually have to resort to casting. Maybe these will improve with
 time.

Yeah they are complex, but they also open ways for powerful optimizations by the compiler. Though I do have to say that inout needs some serious reconsideration, since the way they work currently is ambiguous when you have more than one inout argument, or when you have a delegate parameter with inout arguments.
 - opDispatch. I think it just promotes sloppy, obfuscated code for
 minor syntactical benefit.

Wrong. It's a powerful tool for building runtime dynamic class loading. It allows you to write generic code that Just Works without having to special-case them for statically-known classes vs. dynamic classes. If anything, I'd argue for *more* similar features that let you write generic code that integrates seamlessly into the language. Just because it's been used (arguably abused) for things like making roman numerals or vector swizzling, doesn't mean it's a bad feature.
 Member access through pointers should require -> like in C++ so that
 you can overload it for smart pointer/reference ADTs.

Yikes!! Please don't reintroduce that monstrous -> operator from C++! (Besides, most of the time idiomatic D code doesn't even need pointers.) T -- If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton
Apr 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 11:58:19PM +0200, deadalnix wrote:
[...]
  - is is messed up. It is a massive hack and have to be rationalized.

As I said in another thread, the _functionality_ of various is() expressions are very useful and should be kept. But the _syntax_ is completely b0rked and needs some serious redesign.
  - version is a bad version of static if. The static if part of the
 version must go.

What's your proposal?
  - comma expression is confusing and have very little benefice.

+1. I say that D3 should drop the comma operator. Esp. when doing so will open up the way for having native syntax for tuples. Needing to resort to Phobos to have a way to name a compiler-supported type is backwards and silly.
  - out arguments. We can return tuples, out argument is going
 backward in history.

Not when there's no way to name tuples without resorting to Phobos (or copy-n-paste Phobos code).
  - many array properties (.sort for instance) are useless and would
 be way better as libs.

Yeah, .sort is redundant, and besides shouldn't be an array "property" to begin with. T -- What's a "hot crossed bun"? An angry rabbit.
Apr 28 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was which features in D are redundant and/or 
 do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble and creal types.

 What's your list?

First, I completely agree with some points already made here, and I completely disagree with a few others. A modern compiler should be as powerful and convenient as possible, I completely disagree that a compiler can't do a broad range of things very efficiently _and_ with a smooth learning. Indeed this is what attracted me to D in the first place, the idea that it has the low level power of C++ when you get down to it, but it's also attractive and initially easy to use. What I think should be removed/changed: - Drop is( ... ) and extend "__traits()" (however "__traits" should become .metaof or something along those lines). Also, a easy to understand traits lib should be imported by default like Object.d - Enum as manifest constant - I agree, this is better as "static x = 10" or equivalent. I was actually confused at first when I realized enum's where what was *supposed* to be used for that. - foreach_reverse. Dmitry's gave a good alternative. Though, I think a more intelligent 'foreach' (or even 'for') statement could address this as well. Something like: for (key, value of range, step) { ... } // Where step values which can be deduced at compile time // are used to produce the most optimizated code. - version statements - this would be a lot more consistent as a static if() I think. But it does need a more obvious syntax, possibly something like: static if ("foo" in Compiler.flags) { ... } - .di files - I agree with foobar here. Other language have had this for awhile, and it makes linking a much easier concept. - NaN as default - I've said this before on here, but I think it deserves being said again. FP values defaulting to Nan is a debugging feature, and should be explicitly expressed in areas which need to guarantee a variable is set after declaration. A useful, and consistent default should be used instead. Ints (the other number type) default to zero, and because zero is the most practical and commonly understood, FP values should start here as well. - commas - should be use for tuples and parameters, not as ending marks: int, int foo() { return 5, 6; } auto x, y = 2; // x = 0, y = 2 auto x, y = 2, 3; // x = 2, y = 3 x, y = foo(); // x = 5, y = 6 What should stay: - foreach (or an intelligent 'for' as exampled above). This is an incredibly convenient, tried 'n true feature. - built-in Associative Arrays - one of D's sexiest features. It's very useful for many things, and always having it at your disposal is a logical choice. - properties - another incredibly convenient feature. I think a more sexy implementation of properties are in order, but the construct is great. It would be nice to have properties as a language type, rather than a attribute: struct Foo { property int x { get; private set; } property int y { get() { return x; } set(T t) { x = t; } } } // Or the syntax could follow Types: property x : int { ... } // Which could be templated: property y(T = int) : int { static if (T.isType!int) { ... } else { ... } } - with statement - no reason to kill it really and it's useful in some places. Helps keep code short and readable. - Anonymous class - There's no reason to remove this feature, it's not hurting anyone and it could allow for interesting frameworks similar to jQuery. Other things that would be cool: - static foreach
Apr 28 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-29 04:32, Francois Chabot wrote:
 - properties - another incredibly convenient feature. I think a more
 sexy implementation of properties are in order, but the construct is
 great. It would be nice to have properties as a language type, rather
 than a attribute:

To me, properties are much more than a convenience. The important part of it comes from its existence, not its usage. Quite simply, having properties mean that using public member variables does not break encapsulation (as long as having them part of the public interface is intentional). Without properties, you MUST write accessors for all of them on the off chance that you might want to refactor/delegate them in the future. This adds a huge amount of boilerplate code that ends up wasted time 98% of the time. In short, properties existing, even if not used, end up improving both my efficiency and the legibility of my code.

In principle I agree with you. But in practice this doesn't always work. Take this for example: struct Point { int x; int y; } class Widget { Point point; } void main() { auto w = new Widget; writeln(w.point.x); w.point.x++; writeln(w.point.x); } Prints "0" and "1" as expected. If we now change "point" to a property like this: class Widget { //Point point; Point point_; property Point point () { return point_; } property Point point (Point point) { return point_ = point; } } It will now print "0" and "0". This is a silently breaking change. Sure you can change "point" to return by reference: class Widget { Point point_; property ref Point point () { return point_; } property ref Point point (Point point) { writeln("foo"); point_ = point; return point_; } } Which will print "0" and "1" again. But it won't print "foo", meaning you bypassed the getter. To solve this the compiler would need to perform some kind of property rewriting. Translating: w.point.x++; To: auto __p = w.point; __p.x++; w.point = __p; Also you might need to just as well use properties from the beginning because you need virtual properties. It would help if this was allowed: class Widget { property Point point; } Which would translate to: property Point point () { return point_; } property Point point (Point point) { return point_ = point; } -- /Jacob Carlborg
Apr 29 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 30-04-2012 04:37, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 08:42:23PM +0200, Andrej Mitrovic wrote:
 On 4/29/12, Jacob Carlborg<doob me.com>  wrote:
 In principle I agree with you. But in practice this doesn't always
 work.  Take this for example: Prints "0" and "1" as expected. If we
 now change "point" to a property like this: It will now print "0"
 and "0". This is a silently breaking change. Sure you can change
 "point" to return by reference..

This is a great point and an issue I've ran into and talked about before. The compiler really ought to try and convert a call like this: foo.property++; foo.property+=10; into e.g.: foo.property = foo.property.opAdd(1); foo.property = foo.property.opAdd(10); It would make for some really nice APIs if this feature was available.

To me, the compiler needs to be fixed so that anytime the return value of a property is used as an lvalue, it should always try to call the setter function, or some kind of setter function, instead of the getter (unless there's no setter, in which case it's OK to call the getter). I chalk this up to a compiler issue, not a language issue. T

What you just talked about = semantics. So, it is a language issue. -- - Alex
Apr 29 2012
prev sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"F i L" <witte2008 gmail.com> wrote in message 
news:oakvbobsvtawtdcasglk forum.dlang.org...
 Other things that would be cool:

 - static foreach

We sort of do: // Unrolled at compile-time foreach(T; TypeTuple!(int, string, BigInt)) { ... } I'm not sure that's valid outside a function, though.
Apr 29 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--0023545303b07d90a204bec4989c
Content-Type: text/plain; charset=UTF-8

On 28 April 2012 21:47, Walter Bright <newshound2 digitalmars.com> wrote:

 Andrei and I had a fun discussion last night about this question. The idea
 was which features in D are redundant and/or do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble and
 creal types.

 What's your list?

I personally find the wealth of features in D to be one of it's major selling points. It helps simplify user code a lot, but I think there is room for some things to be more consistent: * version refuses to allow boolean logic, I need boolean logic, thus version is redundant to me. I find myself using static if almost exclusively in its place. I like the *idea*, but it's un-usably limited. * Consolidation of meta/introspection: __traits(), std.traits, is(), and a few other tricks, I often don't know where I should look to perform a particular introspection task. __traits is unsightly, it looks more like a hack rather than a feature, but it fills perhaps one of the most vital roles in the language. * D has a lot of attributes, many of which I haven't used + don't understand. I suspect many of them could be removed and implemented in the library with a proper user attribute system (which would be really useful to compliment D's introspection anyway). This would also free those keywords when those libraries aren't imported/used. * I don't know the value of AA's in the language, I've only used them once or twice. Because AA's can be implemented in numerous ways (map, hash table, etc), and may be ordered or unordered, the the choice of which to use is actually important to the problem more often than not. As long as the same convenience can be achieved in the library (literal expression?), maybe it should be there. --0023545303b07d90a204bec4989c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 28 April 2012 21:47, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Andrei and I had a fun discussion last night about this question. The idea = was which features in D are redundant and/or do not add significant value?<= br> <br> A couple already agreed upon ones are typedef and the cfloat, cdouble and c= real types.<br> <br> What&#39;s your list?<br> </blockquote></div><br><div>I personally find the wealth of features in D t= o be one of it&#39;s major selling points. It helps simplify user code a lo= t, but I think there is room for some things to be more consistent:</div> <div><br></div><div>* version refuses to allow boolean logic, I need boolea= n logic, thus version is redundant to me.=C2=A0I find myself using static i= f almost exclusively in its place. I like the *idea*, but it&#39;s un-usabl= y limited.</div> <div>* Consolidation of meta/introspection: __traits(), std.traits, is(), a= nd a few other tricks, I often don&#39;t know where I should look to perfor= m a particular introspection task. __traits is unsightly, it looks more lik= e a hack rather than a feature, but it fills perhaps one of the most vital = roles in the language.</div> <div>* D has a lot of attributes, many of which I haven&#39;t used + don&#3= 9;t understand. I suspect many of them could be removed and implemented in = the library with a proper user attribute system (which would be really usef= ul to compliment D&#39;s introspection anyway). This would also free those = keywords when those libraries aren&#39;t imported/used.</div> <div>* I don&#39;t know the value of AA&#39;s in the language, I&#39;ve onl= y used them once or twice. Because AA&#39;s can be implemented in numerous = ways (map, hash table, etc), and may be ordered or unordered, the the choic= e of which to use is actually important to the problem more often than not.= As long as the same convenience can be achieved in the library (literal ex= pression?), maybe it should be there.</div> --0023545303b07d90a204bec4989c--
Apr 28 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 00:18, Manu wrote:
 On 28 April 2012 21:47, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:

     Andrei and I had a fun discussion last night about this question.
     The idea was which features in D are redundant and/or do not add
     significant value?

     A couple already agreed upon ones are typedef and the cfloat,
     cdouble and creal types.

     What's your list?


 I personally find the wealth of features in D to be one of it's major
 selling points. It helps simplify user code a lot, but I think there is
 room for some things to be more consistent:

 * version refuses to allow boolean logic, I need boolean logic, thus
 version is redundant to me. I find myself using static if almost
 exclusively in its place. I like the *idea*, but it's un-usably limited.

+1.
 * Consolidation of meta/introspection: __traits(), std.traits, is(), and
 a few other tricks, I often don't know where I should look to perform a
 particular introspection task. __traits is unsightly, it looks more like
 a hack rather than a feature, but it fills perhaps one of the most vital
 roles in the language.
 * D has a lot of attributes, many of which I haven't used + don't
 understand. I suspect many of them could be removed and implemented in
 the library with a proper user attribute system (which would be really
 useful to compliment D's introspection anyway). This would also free
 those keywords when those libraries aren't imported/used.
 * I don't know the value of AA's in the language, I've only used them
 once or twice. Because AA's can be implemented in numerous ways (map,
 hash table, etc), and may be ordered or unordered, the the choice of
 which to use is actually important to the problem more often than not.
 As long as the same convenience can be achieved in the library (literal
 expression?), maybe it should be there.

-- - Alex
Apr 29 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 28 April 2012 at 20:50:30 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 09:22:59PM +0200, q66 wrote:
 - Phobos is too fat - it needs to shrink to just a few core 
 modules,
 others being distributed via some system like CPAN for Perl

Um... that's what a *library* is supposed to be: a large collection of useful stuff from which you can pick the few that you need right now.

And the STL and libc isn't big? Size is only intimidating if you don't know what your looking for. Having to scour in std.ascii, then std.utf, then std.array or other locations when your looking for something can get a little annoying. But it's a learning curve, once you know it you tend to find the functions and information fairly quickly. More likely a good tutorial through the library would alleviate some of that, or just the parts that are more confusing. One part for example involving conversion for unicode, I still have no idea how to convert Latin1String (extended ascii) to utf so I could use all of phobos's power; So I've ended up writing my own little conversion function for that. It's going to come down that stuff we write and post up that we think is self explanatory isn't because as the implementers we understand it in intimately.
Apr 28 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 28 April 2012 at 21:58:47 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 11:42:31PM +0200, Peter Alexander wrote:
 [...]
 - UFCS. It's just sugar, but adds complexity.

On the contrary, it's a major helper for writing generic code. In my new AA implementation, I use UFCS to provide a default toHash function for all types that don't already provide one. Without UFCS, this would require lots of ugly hacks and constraints on how user code can provide custom hash functions. (Due to the way D overloading works, UFCS is currently the only way to provide a default function without causing a conflict at compile-time.)

The problem there is that toHash is a member function. That UFCS is helpful in working around other problems in D is not a good argument for its existence IMO. To be honest, I don't like the idea of member functions at all. Having two syntaxes for calling a function is the core problem, and UFCS is just an extra complication on top of it to try and mitigate the original problem. f(x) ---> x.f() is not progress in language design.
 - const/immutable/inout/shared/pure. These add massive 
 complexity to
 the language for little (IMO) benefit. When I do 
 multi-threading, I
 usually have to resort to casting. Maybe these will improve 
 with
 time.

Yeah they are complex, but they also open ways for powerful optimizations by the compiler.

In theory. IMO the amount of time you spend trying to please the type system could have been better spent optimizing your code manually. No code I have ever written would benefit significantly from these potential optimisations. For example, one optimisation is that pure function calls could be hoisted out of loops. Great, except that if that function call had any significant cost whatsoever, I would have already done that optimisation myself.
 - opDispatch. I think it just promotes sloppy, obfuscated code 
 for
 minor syntactical benefit.

Wrong.

It's my opinion. You are free to disagree, but opinions can't be wrong. I've seen no good uses of opDispatch so far. If you can point me towards some code that justifies its use then please let me know about it.
Apr 28 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300513f69892a604bec4c56c
Content-Type: text/plain; charset=UTF-8

On 29 April 2012 00:42, Peter Alexander <peter.alexander.au gmail.com>wrote:

 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:

 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble and
 creal types.

 What's your list?

Here's my list: - Properties. They add no value and just start pointless discussions about what should and shouldn't be a property. - UFCS. It's just sugar, but adds complexity. - const/immutable/inout/shared/**pure. These add massive complexity to the language for little (IMO) benefit. When I do multi-threading, I usually have to resort to casting. Maybe these will improve with time. - opDispatch. I think it just promotes sloppy, obfuscated code for minor syntactical benefit. Member access through pointers should require -> like in C++ so that you can overload it for smart pointer/reference ADTs. That's all I can think of for now.

I disagree with every one of those points, except maybe 'shared', which seems like a good idea in theory, but I think it's completely broken (every interaction requires an explicit cast, and there is no facility for transfer of ownership, which is a VERY common operation in my experience) --20cf300513f69892a604bec4c56c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 29 April 2012 00:42, Peter Alexander <span di= r=3D"ltr">&lt;<a href=3D"mailto:peter.alexander.au gmail.com">peter.alexand= er.au gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright= wrote:<br> </div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Andrei and I had a fun discussion last night about this question. The idea = was which features in D are redundant and/or do not add significant value?<= br> <br> A couple already agreed upon ones are typedef and the cfloat, cdouble and c= real types.<br> <br> What&#39;s your list?<br> </blockquote> <br></div></div> Here&#39;s my list:<br> <br> - Properties. They add no value and just start pointless discussions about = what should and shouldn&#39;t be a property.<br> <br> - UFCS. It&#39;s just sugar, but adds complexity.<br> <br> - const/immutable/inout/shared/<u></u>pure. These add massive complexity to= the language for little (IMO) benefit. When I do multi-threading, I usuall= y have to resort to casting. Maybe these will improve with time.<br> <br> - opDispatch. I think it just promotes sloppy, obfuscated code for minor sy= ntactical benefit. Member access through pointers should require -&gt; like= in C++ so that you can overload it for smart pointer/reference ADTs.<br> <br> That&#39;s all I can think of for now.<br> </blockquote></div><br><div>I disagree with every one of those points, exce= pt maybe &#39;shared&#39;, which seems like a good idea in theory, but I th= ink it&#39;s completely broken (every interaction requires an explicit cast= , and there is no facility for transfer of ownership, which is a VERY commo= n operation in my experience)</div> --20cf300513f69892a604bec4c56c--
Apr 28 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235452fd84c9b79804bec4e760
Content-Type: text/plain; charset=UTF-8

On 29 April 2012 01:09, F i L <witte2008 gmail.com> wrote:

 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:

 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble and
 creal types.

 What's your list?

First, I completely agree with some points already made here, and I completely disagree with a few others. A modern compiler should be as powerful and convenient as possible, I completely disagree that a compiler can't do a broad range of things very efficiently _and_ with a smooth learning. Indeed this is what attracted me to D in the first place, the idea that it has the low level power of C++ when you get down to it, but it's also attractive and initially easy to use. What I think should be removed/changed: - Drop is( ... ) and extend "__traits()" (however "__traits" should become .metaof or something along those lines). Also, a easy to understand traits lib should be imported by default like Object.d - Enum as manifest constant - I agree, this is better as "static x = 10" or equivalent. I was actually confused at first when I realized enum's where what was *supposed* to be used for that. - foreach_reverse. Dmitry's gave a good alternative. Though, I think a more intelligent 'foreach' (or even 'for') statement could address this as well. Something like: for (key, value of range, step) { ... } // Where step values which can be deduced at compile time // are used to produce the most optimizated code. - version statements - this would be a lot more consistent as a static if() I think. But it does need a more obvious syntax, possibly something like: static if ("foo" in Compiler.flags) { ... } - .di files - I agree with foobar here. Other language have had this for awhile, and it makes linking a much easier concept. - NaN as default - I've said this before on here, but I think it deserves being said again. FP values defaulting to Nan is a debugging feature, and should be explicitly expressed in areas which need to guarantee a variable is set after declaration. A useful, and consistent default should be used instead. Ints (the other number type) default to zero, and because zero is the most practical and commonly understood, FP values should start here as well. - commas - should be use for tuples and parameters, not as ending marks: int, int foo() { return 5, 6; } auto x, y = 2; // x = 0, y = 2 auto x, y = 2, 3; // x = 2, y = 3 x, y = foo(); // x = 5, y = 6 What should stay: - foreach (or an intelligent 'for' as exampled above). This is an incredibly convenient, tried 'n true feature. - built-in Associative Arrays - one of D's sexiest features. It's very useful for many things, and always having it at your disposal is a logical choice. - properties - another incredibly convenient feature. I think a more sexy implementation of properties are in order, but the construct is great. It would be nice to have properties as a language type, rather than a attribute: struct Foo { property int x { get; private set; } property int y { get() { return x; } set(T t) { x = t; } } } // Or the syntax could follow Types: property x : int { ... } // Which could be templated: property y(T = int) : int { static if (T.isType!int) { ... } else { ... } } - with statement - no reason to kill it really and it's useful in some places. Helps keep code short and readable. - Anonymous class - There's no reason to remove this feature, it's not hurting anyone and it could allow for interesting frameworks similar to jQuery. Other things that would be cool: - static foreach

Hear hear. I completely agree with everything you just said. --00235452fd84c9b79804bec4e760 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 29 April 2012 01:09, F i L <span dir=3D"ltr">= &lt;<a href=3D"mailto:witte2008 gmail.com">witte2008 gmail.com</a>&gt;</spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright= wrote:<br> </div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Andrei and I had a fun discussion last night about this question. The idea = was which features in D are redundant and/or do not add significant value?<= br> <br> A couple already agreed upon ones are typedef and the cfloat, cdouble and c= real types.<br> <br> What&#39;s your list?<br> </blockquote> <br></div></div> First, I completely agree with some points already made here, and I complet= ely disagree with a few others.<br> <br> A modern compiler should be as powerful and convenient as possible, I compl= etely disagree that a compiler can&#39;t do a broad range of things very ef= ficiently _and_ with a smooth learning. Indeed this is what attracted me to= D in the first place, the idea that it has the low level power of C++ when= you get down to it, but it&#39;s also attractive and initially easy to use= .<br> <br> <br> <br> What I think should be removed/changed:<br> <br> - Drop is( ... ) and extend &quot;__traits()&quot; (however &quot;__traits&= quot; should become .metaof or something along those lines). Also, a easy t= o understand traits lib should be imported by default like Object.d<br> <br> - Enum as manifest constant - I agree, this is better as &quot;static x =3D= 10&quot; or equivalent. I was actually confused at first when I realized e= num&#39;s where what was *supposed* to be used for that.<br> <br> - foreach_reverse. Dmitry&#39;s gave a good alternative. Though, I think a = more intelligent &#39;foreach&#39; (or even &#39;for&#39;) statement could = address this as well. Something like:<br> <br> =C2=A0 =C2=A0for (key, value of range, step) {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0...<br> =C2=A0 =C2=A0}<br> <br> =C2=A0 =C2=A0// Where step values which can be deduced at compile time<br> =C2=A0 =C2=A0// are used to produce the most optimizated code.<br> <br> - version statements - this would be a lot more consistent as a static if()= I think. But it does need a more obvious syntax, possibly something like:<= br> <br> =C2=A0 =C2=A0static if (&quot;foo&quot; in Compiler.flags) {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0...<br> =C2=A0 =C2=A0}<br> <br> - .di files - I agree with foobar here. Other language have had this for aw= hile, and it makes linking a much easier concept.<br> <br> - NaN as default - I&#39;ve said this before on here, but I think it deserv= es being said again. FP values defaulting to Nan is a debugging feature, an= d should be explicitly expressed in areas which need to guarantee a variabl= e is set after declaration. A useful, and consistent default should be used= instead. Ints (the other number type) default to zero, and because zero is= the most practical and commonly understood, FP values should start here as= well.<br> <br> - commas - should be use for tuples and parameters, not as ending marks:<br=

=C2=A0 =C2=A0int, int foo() { return 5, 6; }<br> <br> =C2=A0 =C2=A0auto x, y =3D 2; =C2=A0 =C2=A0// x =3D 0, y =3D 2<br> =C2=A0 =C2=A0auto x, y =3D 2, 3; // x =3D 2, y =3D 3<br> <br> =C2=A0 =C2=A0x, y =3D foo(); =C2=A0 =C2=A0 // x =3D 5, y =3D 6<br> <br> <br> <br> What should stay:<br> <br> - foreach (or an intelligent &#39;for&#39; as exampled above). This is an i= ncredibly convenient, tried &#39;n true feature.<br> <br> - built-in Associative Arrays - one of D&#39;s sexiest features. It&#39;s v= ery useful for many things, and always having it at your disposal is a logi= cal choice.<br> <br> - properties - another incredibly convenient feature. I think a more sexy i= mplementation of properties are in order, but the construct is great. It wo= uld be nice to have properties as a language type, rather than a attribute:= <br> <br> =C2=A0 =C2=A0struct Foo {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0property int x { get; private set; }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0property int y {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0get() =C2=A0 =C2=A0{ return x; }<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set(T t) { x =3D t; }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br> =C2=A0 =C2=A0}<br> <br> =C2=A0 =C2=A0// Or the syntax could follow Types:<br> <br> =C2=A0 =C2=A0property x : int { ... }<br> <br> =C2=A0 =C2=A0// Which could be templated:<br> <br> =C2=A0 =C2=A0property y(T =3D int) : int {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0static if (T.isType!int) {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0else {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br> =C2=A0 =C2=A0}<br> <br> - with statement - no reason to kill it really and it&#39;s useful in some = places. Helps keep code short and readable.<br> <br> - Anonymous class - There&#39;s no reason to remove this feature, it&#39;s = not hurting anyone and it could allow for interesting frameworks similar to= jQuery.<br> <br> <br> <br> Other things that would be cool:<br> <br> - static foreach<br> </blockquote></div><br><div>Hear hear.</div><div>I completely agree with ev= erything you just said.</div> --00235452fd84c9b79804bec4e760--
Apr 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, April 28, 2012 22:00:52 bearophile wrote:
 2) I'd like to disallow (or fix!) default arguments of out and
 ref arguments (http://d.puremagic.com/issues/show_bug.cgi?id=5850
 ).

If the changes to ref and const ref that were discussed during the beta are fully fleshed out and implemented, then it'll be perfectly legal to pass a temporary value to a ref in many cases (if not in general), in which case having them take a default argument wouldn't be a problem at all. But as long as ref can't take temporaries, having it take a default argument makes no sense at all.
 3) Automatic joining of adjacent strings (a bug-prone
 anti-feature: ["red" "green", "blue"]).

Agreed. - Jonathan M Davis
Apr 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, April 28, 2012 13:43:27 H. S. Teoh wrote:
 D has typedef?? Wow. And I thought I had a good grasp of D.

It did, but it won't. It's either already been deprecated or will be soon. - Jonathan M Davis
Apr 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, April 28, 2012 23:20:42 Adam D. Ruppe wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 What's your list?

I think most the responses to this thread are insane.

LOL. Yeah. Many of them involve completely gutted pieces of the language, and very few discuss "redundant" features like Walter mentioned. - Jonathan M Davis
Apr 28 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 28 April 2012 at 22:33:08 UTC, Timon Gehr wrote:
 - UFCS:
    The complexity comes from having multiple function invocation
    syntaxes. UFCS actually makes that situation better without 
 adding a
    lot of complexity to the compiler implementation.

Exactly. The problem is having multiple function invocation syntaxes. That's one source of complexity, and UFCS add another in attempt to reduce the first cause.
 - const/immutable/shared/pure
    shared: The fact that everything that is not marked as 
 shared is
    actually thread-local is extremely important. I think most 
 other
    imperative languages got this wrong.
    But if shared is explicit in the type system, immutable 
 really
    should be explicit too. The sad part is that the qualifiers 
 don't
    play nicely with reference types at the moment.

I agree with thread-local by default, but that is separate from shared.
 - opDispatch
    This is useful and of significant value if used the right 
 way.

Can you give me an example of it being used the right way?
    I hope you are not actually serious about that '->' part.

I'm serious. I don't like overloaded syntax. foo.bar shouldn't also mean (*foo).bar -- it causes confusion and introduces ambiguities when either could work. Combine this with opDispatch, UFCS and function overloading and your in for some nasty headaches.
Apr 28 2012
prev sibling next sibling parent "q66" <quaker66 gmail.com> writes:
On Saturday, 28 April 2012 at 23:11:17 UTC, Peter Alexander wrote:
 On Saturday, 28 April 2012 at 22:33:08 UTC, Timon Gehr wrote:
 - UFCS:
   The complexity comes from having multiple function invocation
   syntaxes. UFCS actually makes that situation better without 
 adding a
   lot of complexity to the compiler implementation.

Exactly. The problem is having multiple function invocation syntaxes. That's one source of complexity, and UFCS add another in attempt to reduce the first cause.
 - const/immutable/shared/pure
   shared: The fact that everything that is not marked as 
 shared is
   actually thread-local is extremely important. I think most 
 other
   imperative languages got this wrong.
   But if shared is explicit in the type system, immutable 
 really
   should be explicit too. The sad part is that the qualifiers 
 don't
   play nicely with reference types at the moment.

I agree with thread-local by default, but that is separate from shared.
 - opDispatch
   This is useful and of significant value if used the right 
 way.

Can you give me an example of it being used the right way?

vector swizzling! :D
   I hope you are not actually serious about that '->' part.

I'm serious. I don't like overloaded syntax. foo.bar shouldn't also mean (*foo).bar -- it causes confusion and introduces ambiguities when either could work. Combine this with opDispatch, UFCS and function overloading and your in for some nasty headaches.

Apr 28 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright 
 wrote:
 Andrei and I had a fun discussion last night about this 
 question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble
 and creal types.

 What's your list?

D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse).

foreach is very useful. Have you actually used D?

I have used D and didn't claim that foreach isn't useful. What I said that is that it belongs in the library, NOT the language.
 This is nothing more than a fancy function with
 a delegate parameter.

That would be opApply.

Indeed but I'd go even further by integrating it with ranges so that ranges would provide an opApply like method e.g. auto r = BinaryTree!T.preOrder(); // returns range r.each( (T elem) { ...use elem...}); // each method a-la Ruby
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

What is the benefit?

On the one hand the current enum for manifest constants is a hack due to weaknesses of the toolchain and on the other hand it doesn't provide properly encapsulated enums such as for instance the Java 5.0 ones or the functional kind.
 * version - this does not belong in a programming language. Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

It is far better than having a pile of #ifdef styled spaghetti code. I'd expect to have all the OS specific code encapsulated separately anyway, not spread around the code base. Which is the current recommended way of using versions anyway. The inevitable conclusion would be to either use a version management system like git or have separate implementation modules for platform specific code and use the build tool to implement the logic of select the modules to include in the build.
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; 
 Pascal
 units all solved this long ago.

 * This is a big one: get rid of *all* current compile time
 special syntax.

What would that be exactly?

This includes __traits, templates, static ifs, etc..
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?

No I'm joking. The current system is a pile of hacks on top of the broken model of c++ templates. I should be able to use a *very* minimalistic system to write completely _regular_ D code and run it at different times. This is a simple matter of separation of concerns: what we want to execute (what code) is separate to the concern of when we want to execute it.
 This would reduce the size of the language to half of its 
 current
 size, maybe even more.

I am certain that it would not. You missed to present the 'general purpose mechanisms'.

Apr 28 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Peter Alexander:

 f(x) ---> x.f() is not progress in language design.

I used to think the same. But Haskell offers "." and $ to chain functions and remove parentheses, F# has the |> pipe operator. In D UCFS is almost equally useful to turn nesting of function calls in a more readable chain. In functional-style code this makes a lot of difference, turning: foo(bar(copy(baz(a), spam(b)))) Into: baz(a).copy(b.spam()).bar().foo() When I see 3+ nested parentheses I find it hard to read the expression. While a chain is easy to read.
 In theory. IMO the amount of time you spend trying to please 
 the type system could have been better spent optimizing your 
 code manually.

 No code I have ever written would benefit significantly from 
 these potential optimisations. For example, one optimisation is 
 that pure function calls could be hoisted out of loops. Great, 
 except that if that function call had any significant cost 
 whatsoever, I would have already done that optimisation myself.

I used to write lot of D1 code too, and I've seen that managing D2 const-related issues slows down significantly my coding compared to D1 coding, so undeniably they have a cost. But in D the main purpose of "pure" is not as optimization tool, but more as a tool to enforce a better coding style, that makes code understanding (and testing simpler), and helps avoid some bugs, coming from using variables from outer scopes. Bye, bearophile
Apr 28 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
Peter Alexander wrote:
 - opDispatch
   This is useful and of significant value if used the right 
 way.

Can you give me an example of it being used the right way?

It can be very useful for jQuery/JSON style dynamic objects: import std.variant, std.stdio; struct Dynamic { Variant[string] vars; void opDispatch(string key)() property { return vars[key]; } void opDispatch(string key, T)(T value) property { vars[key] = value; } } void main() { auto foo = Dynamic(); foo.a = "A"; foo.b = 11; writefln("%s, %s", foo.a, foo.b); }
   I hope you are not actually serious about that '->' part.

I'm serious. I don't like overloaded syntax. foo.bar shouldn't also mean (*foo).bar -- it causes confusion and introduces ambiguities when either could work. Combine this with opDispatch, UFCS and function overloading and your in for some nasty headaches.

Craziness. What could you possibly gain is there in forcing a pointer distinction at every point that it's used? We already declared the variable as a pointer, we don't need to be reminded of that fact at every line.
Apr 28 2012
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29.04.2012 4:31, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 01:54:35 Peter Alexander wrote:
 On Saturday, 28 April 2012 at 23:37:14 UTC, F i L wrote:
 Peter Alexander wrote:
 I'm serious. I don't like overloaded syntax.  foo.bar
 shouldn't also mean (*foo).bar -- it causes confusion and
 introduces ambiguities when either could work. Combine this
 with opDispatch, UFCS and function overloading and your in for
 some nasty headaches.

Craziness. What could you possibly gain is there in forcing a pointer distinction at every point that it's used? We already declared the variable as a pointer, we don't need to be reminded of that fact at every line.

It matters when you have things that imitate pointers (e.g. smart pointers). Those will have their own members, separate from the pointee's members, so ptr.foo could refer to the smart pointer's members or the pointee's members.

For better or worse, the solution for smart pointers in D would be to use opDispatch,

*cough* alias this *cough* but it _does_ still mean that the type pointed to can't have any
 of the same functions as the smart pointer (or at least, they would have to be
 called differently, since . would use opDispatch and therefore use the smart
 pointer's function), so you _do_ lose something over the ->  syntax here.
 However, the overall gain is usability probably still outweighs that. I
 wouldn't exactly have been heartbroken if ->  had been in D, but simplicity of
 not needing it can be very nice - and it can be invaluable in the case of
 templates, because then you don't have to distinguish between structs,
 pointers to structs, and classes when calling functions on them.

 - Jonathan M Davis

-- Dmitry Olshansky
Apr 28 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29.04.2012 10:42, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 09:53:15 Dmitry Olshansky wrote:
 On 29.04.2012 4:31, Jonathan M Davis wrote:
 For better or worse, the solution for smart pointers in D would be to use
 opDispatch,

*cough* alias this *cough*

That's not necessarily a good idea, depending on how it's used. You want to avoid having the smart pointer implicitly convert to what it holds such that a reference to it leaks. If you're dealing with a pointer to a struct, and alias this aliases to the struct (rather than the pointer), then you're okay. But if you're dealing with a class, you don't have that option. So, alias this ends up leaking a reference to the class, which defeats the purpose of the smart pointer. You have the same problem if alias this aliases to the pointer rather than what's pointed to.

Point taken.
 But regardless of whether you use alias this or opDispatch, you have the same
 problem with regards to ->. In C++, . would be used to call the smart
 pointer's functions, and ->  would be used to call functions on the object
 pointed to. In D, the two aren't distinguished - both use . - so you can't
 have any functions on the type pointed to which conflict with the smart
 pointer's functions, or you won't be able to call them (unless another way to
 call them is provided somehow). So, it's definitely something that C++ does
 better with as far as that goes.

So you just need not to have any _member_ functions on smart pointer? Just use free functions that take SmartPointer!T. UFCS may also lend a hand if T and SmartPointer do not have ambiguous funcs. -- Dmitry Olshansky
Apr 29 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 28 April 2012 at 21:19:00 UTC, H. S. Teoh wrote:
 On Sat, Apr 28, 2012 at 10:07:54PM +0200, q66 wrote:
 On Saturday, 28 April 2012 at 20:04:11 UTC, Walter Bright

written that code before, and it's general enough for everyday use, then you shouldn't need to download this, install that, configure the other, before you can use it. It's a major plus if you're publishing code to be able to say, just download my sources and compile it with the language standard library and it will all work. As opposed to, if you want to compile my code, you need library X and Y which depend on W and Z, all of which have to be downloaded from different places all over the 'net and you better make sure you get the right versions otherwise everything will break.

OMG I love you :) A long time ago when I began programming I came to a distinct conclusion that anything I write has to be able to compile and just work with only the standard library. I don't want to make people go out of their way to get this or that. * If you have something that requires multimedia, then fine a library will help. * If you have to have something that does translations between other languages and makes sense, then use it. But for everything that's just basic work processing and otherwise, there is no reason you should have an external library used. Need compression? If the standard library (like C) doesn't include something, then what do you choose? LZMA? lzop? gzip/zlib? bzip2? Depends on how heavy duty you need. If a basic compression is included then you will use it unless you REALLY need the extra speed or compression ratio. "Make everything as simple as possible, but no simpler." -- Albert Einstein
Apr 28 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 28 April 2012 at 23:29:35 UTC, bearophile wrote:
 Peter Alexander:

 f(x) ---> x.f() is not progress in language design.

I used to think the same. But Haskell offers "." and $ to chain functions and remove parentheses, F# has the |> pipe operator. In D UCFS is almost equally useful to turn nesting of function calls in a more readable chain. In functional-style code this makes a lot of difference, turning: foo(bar(copy(baz(a), spam(b)))) Into: baz(a).copy(b.spam()).bar().foo() When I see 3+ nested parentheses I find it hard to read the expression. While a chain is easy to read.

What D does and what Haskell does are very different things. D has (at least) two types of functions: free functions and member functions. UFCS makes free functions look like member functions. In Haskell, $ just gives you a way of re-ordering precedence -- it doesn't hide anything. This matters because UFCS in D is deceitful. It makes you think the free function is a member function when it is not. struct Foo { void bar() {} } void baz(Foo f) {} Foo f; f.bar(); // ok f.baz(); // ok, looks like baz is a member function auto pbar = &Foo.bar; // ok auto pbaz = &Foo.baz; // error! IMO, D would be better with Haskell's function calling syntax (of course, this would require many, many other syntactical changes).
 But in D the main purpose of "pure" is not as optimization 
 tool, but more as a tool to enforce a better coding style, that 
 makes code understanding (and testing simpler), and helps avoid 
 some bugs, coming from using variables from outer scopes.

True, but I'm quite happy to write pure functions without the static checking. I do not believe that the safety provided by the static checks outweighs the development cost of ensuring you have the correct qualifiers everywhere.
Apr 28 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 23:25:10 UTC, foobar wrote:
 On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright 
 wrote:
 Andrei and I had a fun discussion last night about this 
 question. The
 idea was which features in D are redundant and/or do not add
 significant value?

 A couple already agreed upon ones are typedef and the 
 cfloat, cdouble
 and creal types.

 What's your list?

D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse).

foreach is very useful. Have you actually used D?

I have used D and didn't claim that foreach isn't useful. What I said that is that it belongs in the library, NOT the language.

Well, it's your opinion. But I bet it's not the opinion of thousands of programmers, it's not the opinion of the Java/C# designers, and I even believe they wanted to add foreach in C++ (or is it already the case ?). Putting things in the library isn't the solution for everything: it's often hard (if possible) to make it work as well as in the core language, and error messages are usually more cryptic. Basic features like this should stay in the core language in my opinion.
 This is nothing more than a fancy function with
 a delegate parameter.

That would be opApply.

Indeed but I'd go even further by integrating it with ranges so that ranges would provide an opApply like method e.g. auto r = BinaryTree!T.preOrder(); // returns range r.each( (T elem) { ...use elem...}); // each method a-la Ruby
 * enum - enum should be completely redesigned to only 
 implement
 what it's named after: enumerations.

What is the benefit?

On the one hand the current enum for manifest constants is a hack due to weaknesses of the toolchain and on the other hand it doesn't provide properly encapsulated enums such as for instance the Java 5.0 ones or the functional kind.
 * version - this does not belong in a programming language. 
 Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

It is far better than having a pile of #ifdef styled spaghetti code. I'd expect to have all the OS specific code encapsulated separately anyway, not spread around the code base. Which is the current recommended way of using versions anyway. The inevitable conclusion would be to either use a version management system like git or have separate implementation modules for platform specific code and use the build tool to implement the logic of select the modules to include in the build.

No it isn't. Ask the kernel hackers why they still use #ifdef instead of using hundreds of git branches for every feature and platform they must maintain.
 * di files - a library should encapsulate all the info 
 required
 to use it. Java Jars, .Net assemblies and even old school; 
 Pascal
 units all solved this long ago.

 * This is a big one: get rid of *all* current compile time
 special syntax.

What would that be exactly?

This includes __traits, templates, static ifs, etc..
 It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons.

Are you serious?

No I'm joking. The current system is a pile of hacks on top of the broken model of c++ templates. I should be able to use a *very* minimalistic system to write completely _regular_ D code and run it at different times. This is a simple matter of separation of concerns: what we want to execute (what code) is separate to the concern of when we want to execute it.
 This would reduce the size of the language to half of its 
 current
 size, maybe even more.

I am certain that it would not. You missed to present the 'general purpose mechanisms'.


You should use Go. It fits better to your views about programming languages than D.
Apr 28 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Saturday, 28 April 2012 at 21:02:25 UTC, H. S. Teoh wrote:
 [...]
 I disagree. Having a dedicated foreach construct allows the 
 compiler to
 optimize away the delegate in certain cases. I wouldn't want to 
 incur
 the cost of creating and passing a delegate in something as 
 simple as
 foreach (i; 0..100), for example.

There is no reason why this should be special cased for a specific redundant construct in the language. Shouldn't I enjoy similar optimization techniques when using other kinds of functions with delegate parameters?
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

Actually, I rather like the enum idiom of declaring compile-time constants. Though it could do with a renaming to something more befitting.
 * version - this does not belong in a programming language. Git
 is a much better solution.

This is an interesting idea. But using separate git branches just for having versioned code seems a bit like total overkill... plus a maintenance nightmare since you have to continue pull and merge changes to every porting branch every time development happens. Whereas having everything represented in source means that whoever writes a new feature is also responsible for making it work with whatever versions are currently out there. After-the-fact fixes are always painful.
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; 
 Pascal
 units all solved this long ago.

I proposed a while ago that .di files should be replaced by something better: omit ALL function bodies, template bodies, private members, etc., and just keep the "real" public API in the human-readable part of the file. Function and template bodies should be kept in as a binary blob readable by the compiler (which obviously needs to know them otherwise it won't be able to expand templates). (Yes the binary blob can be reverse-engineered, but so can executables, so it's a moot point. We're not trying to write cryptographic security here, but it's nice to separate what the compiler needs to know vs. what the user of a library needs to know.)

I agree with the general notion here. Whatever the actual implementation details are, the API should be strongly tied to the binary in order to insure consistency and ease of use. I shouldn't need to worry if the header files match the binary library. Regarding the human readable API - that's why we have documentation for.
 * This is a big one: get rid of *all* current compile time
 special syntax. It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons. This
 would reduce the size of the language to half of its current
 size, maybe even more.

I have to disagree here. CTFE and compile-time features is a major reason I like D. I argue rather that compile-time features should be *improved*. The current situation is good, but not quite there yet. It can be made better. T

Please see my other reply to Timor. "compile-time" is simply the run-time of the compiler and shouldn't require any special syntax. E.g. D currently requires me to use pragma to output a message during compilation whereas I think it would be much cleaner to simply use writeln() in a component loaded and run by the compiler during compilation of my target code.
Apr 28 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 01:42:05 bearophile wrote:
 Jonathan M Davis:
 - 'in' operator returning a pointer to the element.

Really? I use that all the time with AAs. Without that, you would have to do two lookups to get an object which might not be in the container, so it would be less efficient.

LDC1 compiler introduced a small optimization, it looks for nearby associative array lookups and removes the second of them where possible. In my code I have seen this frees me to use "in" nearby followed by [], with the same efficiency of a single AA lookup. With this small optimization, D "in" is free to return a more clean boolean.

I really don't see anything "unclean" about returing a pointer. It does the job fantastically, and you can use it in conditional expressions just like you would use a bool. Also, while it may work for the most part, I'd be very skeptical about the compiler being able to optimize out lookups as well as simply using in would - especially in cases where you don't immediately use the pointer.
 This optimization doesn't work if you want to store the pointer
 returned by "in" to use it later, but in my code this pattern
 doesn't happen, I think it's quite uncommon.

Storing it for later use within the function is quite common. Storing it in a member variable or the like should be _very_ uncommon, since it's almost always a bad idea. But even just storing it in a local variable to use later could destroy the locality enough to defeat LDC's optimization. - Jonathan M Davis
Apr 28 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 10:20 AM, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 10:07:38 David Nadlinger wrote:
 On Saturday, 28 April 2012 at 23:51:43 UTC, Jonathan M Davis

 wrote:
 But even just storing it in a local variable to use later
 could destroy the locality enough to defeat LDC's optimization.

Huh? I can't think of a situation where a hash table lookup would entail less indirections than dereferencing a pointer stored in a register (resp. the stack, depending on scheduling).

If you have something like if(key in aa) { // lots of code func(aa[key]); } the compiler is not necessarily going to be able to determine that the AA has not been changed such that aa[key] can use the same lookup that key in aa did rather than redoing the lookup. A prime example would be if(key in aa) { foo(aa); func(aa[key]); } The compiler doesn't necessarily know that foo won't remove key from aa, so it can't save the result of key in aa to reuse rather than calling aa[key], whereas the programmer could know that foo doesn't do anything to aa which would make a pointer to the element invalid and can guarantee that only one lookup occurs by doing if(auto value = key in aa) { foo(aa); func(value); } And that's just one case where the compiler can't make such an optimization but the programmer can. It's _far_ better iMHO to have in return a pointer than to rely on the compiler removing extraneous lookups. - Jonathan M Davis

Well, what if the programmer "knows" that foo does not change 'aa', but it actually does? Then there would possibly be a segmentation fault. This implies that the 'in' operator cannot be used in safe code. (Or there would have to be a special case, that allows 'in' if the result is directly cast to bool.)
Apr 29 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 04:21 AM, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 01:46:25AM -0700, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 10:37:10 Timon Gehr wrote:
 Well, what if the programmer "knows" that foo does not change 'aa',
 but it actually does? Then there would possibly be a segmentation
 fault.  This implies that the 'in' operator cannot be used in  safe
 code. (Or there would have to be a special case, that allows 'in' if
 the result is directly cast to bool.)

It's exactly as safe as any iterator or range which could be invalidated - both of which can occur in safe code. Any of those could blow up in entertaining ways if you use them after they've been invalidated. Pointers are considered safe. It's pointer arithmetic which isn't.

I get that this discussion is about what type 'in' should return, but taking a step back, isn't it all moot because you could just use the .get() method? T

The AA might actually contain the provided default value, so 'get' is not always a good match.
Apr 30 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 28 April 2012 at 23:37:14 UTC, F i L wrote:
 Peter Alexander wrote:
 - opDispatch
  This is useful and of significant value if used the right 
 way.

Can you give me an example of it being used the right way?

It can be very useful for jQuery/JSON style dynamic objects: import std.variant, std.stdio; struct Dynamic { Variant[string] vars; void opDispatch(string key)() property { return vars[key]; } void opDispatch(string key, T)(T value) property { vars[key] = value; } } void main() { auto foo = Dynamic(); foo.a = "A"; foo.b = 11; writefln("%s, %s", foo.a, foo.b); }

This is a perfect example of misuse. Glancing at that code, it looks like foo has two member variables. It is also not clear that each access involves a hash-table lookup. Why abuse well-understood syntax when there are simpler ways to solve the problem?
  I hope you are not actually serious about that '->' part.

I'm serious. I don't like overloaded syntax. foo.bar shouldn't also mean (*foo).bar -- it causes confusion and introduces ambiguities when either could work. Combine this with opDispatch, UFCS and function overloading and your in for some nasty headaches.

Craziness. What could you possibly gain is there in forcing a pointer distinction at every point that it's used? We already declared the variable as a pointer, we don't need to be reminded of that fact at every line.

It matters when you have things that imitate pointers (e.g. smart pointers). Those will have their own members, separate from the pointee's members, so ptr.foo could refer to the smart pointer's members or the pointee's members.
Apr 28 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, April 28, 2012 11:47:31 Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The idea
 was which features in D are redundant and/or do not add significant value?
 
 A couple already agreed upon ones are typedef and the cfloat, cdouble and
 creal types.
 
 What's your list?

Well, that's a hard one. There isn't much in the language that I'd remove even if we were doing a complete redesign without caring about backwards compatibility. Most of the stuff that I'd change is already being (or has been) changed. And while D isn't exactly big, it doesn't tend to have dark corners like C++ does. I'm sure that I don't fully grasp everything in D, but it's fairly rare that I run into something that surprises me or that I thought that I understood but don't (though it still does happen sometimes). With C++, it always feels like there's some new detail that pops up that I didn't have a clue about - or that maybe I _did_ know about but had forgotten because of the insane number of little details that C++ has. One _big_ difference between D and C++ as far as complexity goes is that in C++, a _lot_ of the complexity comes from weird things in the language and knowing about how certain things can go horribly wrong (e.g. I can never remember all of the details on how horribly broken multiple inheritence is). It's frequently not an issue of knowing how to do things in the language but rather an issue of knowing what weird side effects an problems happen with certain stuff. With D, on the other hand, the complexity tends to be in just knowing what all of the features are and what they can do. The only feature that comes to mind as probably being overly complex is is expressions, but that complexity can really come in handy sometimes. std.traits should probably do more to alleviate the need for is expressions though so that odds of needing some of the more complicated stuff are lessened. * As for redundant features, the first one that really comes to mind is WYSIWYG string literals. There are what, 4 different types of delimiters for string literals? I don't even remember all of the options. I just always use ` if I don't want any escaping in string literal and " if I do. The others may be valuable enough to have in some contexts, but I _never_ use them. * version vs static if seems kind of redundant, but it isn't really. version is used for a very specific subset of conditional code compilation, and you can define versions on the command line, whereas static if generally checks code properties (like if a type meets certain conditions). So, I think that they should probably be left as is. There would be some value in allowing a list of versions to be given (rather than using logical operators) in order to avoid duplicate code - e.g. version(linux, FreeBSD) {} else version(MacOSX) {} else version(Windows) {} else static assert(0); but that's about the only thing that I'd change with version. And I wouldn't want to get rid of it. * foreach_reverse is essentially redudant at this point (not to mention confusing if combined with delegates), since we have retro. But we might already be planning to get rid of that. I'm not sure though. * I hate C style struct initializers and would really like to see them go, but for reasons that I don't understand, people actually use them rather than using a proper constructor call, so I doubt that we could get rid of them without a fair bit of complaining. I think that they're completely redundant and very _un_D. * There seem to be too many ways to do variadic functions. We have to allow C style variadics for extern(C), but having 3 of our own seems like a bit much. Variadic templates are generally all that we need. The others don't seem necessary for the most part. But unfortunately, they should probably be left in so that classes can use them with virtual functions, since they can't use templates. * As for features that add little value, the first one that comes to mind is with. I think that I've used it all of once, and I don't think that I've seen it in other people's code very often. It's hard to grep for (since with is used in comments quite often), but it wouldn't surprise me at all if Phobos doesn't use it at all. Also, I fear that not only does it add little value but that it has a tendency to make code less readable. * Increasingly, I don't like UFCS. I think that in most cases, it complicates code for little value. And I _really_ don't like how it results in people flipping chains of a(b(c(d(5)))) calls into something like d(5).c().b.().a(). I think that it makes the code way harder to read. The code is completely backwards. But I appear to be in the minority with that opinion. I also don't like how it creates so many ways to write exactly the same code. It harms readibility. But as much as I dislike many of the applications of UFCS, it _does_ appear to be quite popular. And upon occasion, it may be useful, but I _am_ wishing that we hadn't added it. There are definitely features that I never use (e.g. opDispatch), but for the most part, I think that they're stuff that adds real value for certain types of stuff that I just don't do, so removing them wouldn't really make any sense. Overall, I think that D's feature set is fairly solid. It's mostly just the implementation of said features which is a problem - though some minor tweaks are probably in order (e.g. as Bearophile suggests, make it so that adjacent string literals don't concatenate). - Jonathan M Davis
Apr 28 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29.04.2012 5:06, bearophile wrote:
 Jonathan M Davis:

 * foreach_reverse is essentially redudant at this point (not to mention
 confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient.

bleh C++ doesn't have reverse loop in the language. all there is rbegin() and rend(). And this attitude reminds me of the old STL days. What's wrong with you people? Am I back to 90s ?
 Loops _must_ be fully efficient, they are a basic language construct,
 this is very important. Even foreach() is sometimes not equally
 efficient as a for() in some cases...

Yesterday I tried GDC. Damn I didn't regret it :)
 * I hate C style struct initializers and would really like to see them
 go, but
 for reasons that I don't understand, people actually use them rather
 than using a proper constructor call,

For single structs I prefer D-style initialization. But take a look at this code, if you replace those C-style initializers with D-style, even using aliases to shorten the code to single letters, that data section becomes more noisy: http://rosettacode.org/wiki/Ray-casting_algorithm#D

[snip reasonable parts ;)] -- Dmitry Olshansky
Apr 28 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 30/04/2012 04:52, H. S. Teoh a écrit :
 On Sun, Apr 29, 2012 at 10:03:43AM +0400, Dmitry Olshansky wrote:
 On 29.04.2012 5:06, bearophile wrote:

 Loops _must_ be fully efficient, they are a basic language construct,
 this is very important. Even foreach() is sometimes not equally
 efficient as a for() in some cases...

Yesterday I tried GDC. Damn I didn't regret it :)

Unfortunately, even GDC doesn't inline opApply and its delegate for the simplest of loops: struct S { int data[]; int opApply(int delegate(ref int) dg) { foreach (d; data) { if (auto r = dg(d)) return r; } return 0; } } void main() { S s; foreach (e; s) { writeln(e); } } I think it's because the front-end always generates the full delegate passing code without inlining anything. IMO, this case *need* to be aggressively inlined in order to make D's generic programming capabilities a stronger selling point. T

It is an implementation issue (a real and serious one, but still). It should be fixed by implementation, not language design.
Apr 30 2012
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 03:06, bearophile wrote:
 Jonathan M Davis:

 * foreach_reverse is essentially redudant at this point (not to mention
 confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...
 * I hate C style struct initializers and would really like to see them
 go, but
 for reasons that I don't understand, people actually use them rather
 than using a proper constructor call,

For single structs I prefer D-style initialization. But take a look at this code, if you replace those C-style initializers with D-style, even using aliases to shorten the code to single letters, that data section becomes more noisy: http://rosettacode.org/wiki/Ray-casting_algorithm#D
 * As for features that add little value, the first one that comes to
 mind is
 with. I think that I've used it all of once, and I don't think that
 I've seen
 it in other people's code very often.

It's rather common in Pascal/Delphi programming. I use it now and then. For a case where it's very handy see here, with an enumeration: http://rosettacode.org/wiki/Stable_marriage_problem#Alternative_version
 It's hard to grep for (since with is
 used in comments quite often),

Try to search for "with(" or "with\s(", that are less common in normal text.
 * Increasingly, I don't like UFCS. I think that in most cases, it
 complicates
 code for little value. And I _really_ don't like how it results in people
 flipping chains of a(b(c(d(5)))) calls into something like
 d(5).c().b.().a(). I
 think that it makes the code way harder to read.

For me it makes that kind of code way simpler to read...

Completely agree.
 The code is completely backwards.

It means call d on 5, then call c on the result, then call b on the result, and then call a on the result. It's better than before :-)

Amen.
 Bye,
 bearophile

-- - Alex
Apr 29 2012
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 03:40, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 03:06:53 bearophile wrote:
 * Increasingly, I don't like UFCS. I think that in most cases,
 it complicates
 code for little value. And I _really_ don't like how it results
 in people
 flipping chains of a(b(c(d(5)))) calls into something like
 d(5).c().b.().a(). I
 think that it makes the code way harder to read.

For me it makes that kind of code way simpler to read...
 The code is completely backwards.

It means call d on 5, then call c on the result, then call b on the result, and then call a on the result. It's better than before :-)

I know that you find easier to read. A number of people do. But it is just so backwards in comparison to how stuff normally works, that it hurts my brain. But I've done enough functional programming that I find something likea(b(c(d(5)))) to be completely straightforward, and for some reason not everyone does. And while I _never_ intend to use UFCS in this manner, I'm going to forever have to read the code of others who do, which I find to be a major negative.

I've done ML, F#, Erlang, Haskell, Lisp, and others, and I still don't like that style. It's the very reason F# has the pipelining operators like |> and <|.
 But regardless of my personal opinion on the matter, it's clear that enough
 people like UFCS that it's not going anywhere unless something seriously wrong
 is found with it which makes it untenable.

 - Jonathan M Davis

-- - Alex
Apr 29 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 29/04/2012 03:06, bearophile a Ă©crit :
 Jonathan M Davis:

 * foreach_reverse is essentially redudant at this point (not to mention
 confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...

This is an implementation issue and shouldn't be an argument for language design.
Apr 29 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 23:54, Peter Alexander wrote:
 On Sunday, 29 April 2012 at 21:18:40 UTC, deadalnix wrote:
 Le 29/04/2012 03:06, bearophile a Ă©crit :
 Jonathan M Davis:

 * foreach_reverse is essentially redudant at this point (not to mention
 confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...

This is an implementation issue and shouldn't be an argument for language design.

The 'sufficiently smart compiler' argument is old and invalid. Please do not use it.

Indeed; at some point, you have to admit that implementation will have some impact on design. We don't live an ideal world, unfortunately. ;) -- - Alex
Apr 29 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 30.04.2012 1:54, Peter Alexander wrote:
 On Sunday, 29 April 2012 at 21:18:40 UTC, deadalnix wrote:
 Le 29/04/2012 03:06, bearophile a Ă©crit :
 Jonathan M Davis:

 * foreach_reverse is essentially redudant at this point (not to mention
 confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...

This is an implementation issue and shouldn't be an argument for language design.

The 'sufficiently smart compiler' argument is old and invalid. Please do not use it.

Right, nowdays any compiler is either smart enough or a dead meat that nobody uses. P.S. dmd is kind of work in progress ;) -- Dmitry Olshansky
Apr 30 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 30.04.2012 13:21, SomeDude wrote:
 On Monday, 30 April 2012 at 07:37:13 UTC, Dmitry Olshansky wrote:

Right, nowdays any compiler is either smart enough or a dead meat that nobody uses. P.S. dmd is kind of work in progress ;)

A smart enough compiler would understand natural language and turn it into efficient assembly. :o)

Yeah, unless it decides to take a vacation. :) Or you know such a compiler may have a lot of more interesting things to do so our mundane ideas may just have to wait for a while. -- Dmitry Olshansky
Apr 30 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 29/04/2012 23:54, Peter Alexander a Ă©crit :
 On Sunday, 29 April 2012 at 21:18:40 UTC, deadalnix wrote:
 Le 29/04/2012 03:06, bearophile a Ă©crit :
 Jonathan M Davis:

 * foreach_reverse is essentially redudant at this point (not to mention
 confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...

This is an implementation issue and shouldn't be an argument for language design.

The 'sufficiently smart compiler' argument is old and invalid. Please do not use it.

This is a case by case issue. You should consider fixing implementation issue with implementation, and consider language design if that first one fail. If you don't think this is right, the only rational solution you have is to use assembly directly. As you fail to show how this is something that isn't reasonably implementable, you have no argument.
Apr 30 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 04:47 AM, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 03:06:53AM +0200, bearophile wrote:
 Jonathan M Davis:

 * foreach_reverse is essentially redudant at this point (not to
 mention
 confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...

IMO, the compiler needs to _aggressively_ inline opApply() delegates, unless it's impossible (e.g. opApply is recursive), or perhaps exceeds some reasonable size limit for loop inlining). It's rather disheartening to design a great abstract type for manipulating collections, only to have opApply always incur the overhead of allocating

Use a scope delegate in the opApply signature to avoid the allocation.
 and invoking a
 delegate _every loop iteration_, even when opApply is as simple as:

 	int opApply(int delegate(ref T arg) dg) {
 		someSetupCode();
 		for (i=0; i<n; i++) {
 			dg(element[i]);
 		}
 		someCleanupCode();
 	}

 As far as I'm concerned, the compiler *should* just inline the whole
 thing (both opApply and the delegate body) when you write foreach(c;
 container) {...}. There's no reason for such a trivial loop to incur a
 call to a delegate every iteration.

 Powerful abstractions such as opApply need to be optimized to the max,
 so that D's generic programming capabilities can be a strong selling
 point.


 T

Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 23:54:36 UTC, Peter Alexander wrote:
 It matters when you have things that imitate pointers (e.g. 
 smart pointers). Those will have their own members, separate 
 from the pointee's members, so ptr.foo could refer to the smart 
 pointer's members or the pointee's members.

So basically, for your very specific issue, you want to ditch a syntax that 99% of people actually prefer. I must say you are the very first person I see *anywhere* who actually complains about the . notation and would rather go back to ->.
Apr 28 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 28 April 2012 at 23:25:10 UTC, foobar wrote:
 On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
 On 04/28/2012 09:58 PM, foobar wrote:
 * version - this does not belong in a programming language. 
 Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

It is far better than having a pile of #ifdef styled spaghetti code. I'd expect to have all the OS specific code encapsulated separately anyway, not spread around the code base. Which is the current recommended way of using versions anyway. The inevitable conclusion would be to either use a version management system like git or have separate implementation modules for platform specific code and use the build tool to implement the logic of select the modules to include in the build.

Aren't both of those just side effects of bad design? Most #ifdef calls were to overcome limits in the language that probably overloading would have resolved. I haven't done large projects code beyond my own, and the one or two I've seen were actually done in java. All Architecture and OS specific code should be hopefully done in just one file; That way ugly or special purpose code could be limited to one spot. Not only that but the rest of the code should be clean and you can build another architecture or system with minimal work. Course there will be cases where a lot of work would be needed, or in other cases no work at all.
Apr 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 01:54:35 Peter Alexander wrote:
 On Saturday, 28 April 2012 at 23:37:14 UTC, F i L wrote:
 Peter Alexander wrote:
 I'm serious. I don't like overloaded syntax.  foo.bar
 shouldn't also mean (*foo).bar -- it causes confusion and
 introduces ambiguities when either could work. Combine this
 with opDispatch, UFCS and function overloading and your in for
 some nasty headaches.

Craziness. What could you possibly gain is there in forcing a pointer distinction at every point that it's used? We already declared the variable as a pointer, we don't need to be reminded of that fact at every line.

It matters when you have things that imitate pointers (e.g. smart pointers). Those will have their own members, separate from the pointee's members, so ptr.foo could refer to the smart pointer's members or the pointee's members.

For better or worse, the solution for smart pointers in D would be to use opDispatch, but it _does_ still mean that the type pointed to can't have any of the same functions as the smart pointer (or at least, they would have to be called differently, since . would use opDispatch and therefore use the smart pointer's function), so you _do_ lose something over the -> syntax here. However, the overall gain is usability probably still outweighs that. I wouldn't exactly have been heartbroken if -> had been in D, but simplicity of not needing it can be very nice - and it can be invaluable in the case of templates, because then you don't have to distinguish between structs, pointers to structs, and classes when calling functions on them. - Jonathan M Davis
Apr 28 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
On Saturday, 28 April 2012 at 23:54:36 UTC, Peter Alexander wrote:
 On Saturday, 28 April 2012 at 23:37:14 UTC, F i L wrote:
 Peter Alexander wrote:
 - opDispatch
 This is useful and of significant value if used the right 
 way.

Can you give me an example of it being used the right way?

It can be very useful for jQuery/JSON style dynamic objects: import std.variant, std.stdio; struct Dynamic { Variant[string] vars; void opDispatch(string key)() property { return vars[key]; } void opDispatch(string key, T)(T value) property { vars[key] = value; } } void main() { auto foo = Dynamic(); foo.a = "A"; foo.b = 11; writefln("%s, %s", foo.a, foo.b); }

This is a perfect example of misuse. Glancing at that code, it looks like foo has two member variables. It is also not clear that each access involves a hash-table lookup. Why abuse well-understood syntax when there are simpler ways to solve the problem?

It's not abuse, it's design. That's why I called the type "Dynamic" so the user has an idea about what it is. You could make your same arguments against ever using a Variant object. When you have to manipulate a DOM or XML tree, there's reason why people prefer languages that syntactically interface with those dynamic structure very well. D simply powerful enough to provide a way for programmers to do both. Btw, it's just as unclear that any property (or function) doesn't look through a hash-table or any other number of performance pitfalls if used without any insight into _how_ to use it. This is why we have documentation for libraries, it's impractical cater the language to the idea that coders wont understand the objects their working with to a basic degree.
 I hope you are not actually serious about that '->' part.

I'm serious. I don't like overloaded syntax. foo.bar shouldn't also mean (*foo).bar -- it causes confusion and introduces ambiguities when either could work. Combine this with opDispatch, UFCS and function overloading and your in for some nasty headaches.

Craziness. What could you possibly gain is there in forcing a pointer distinction at every point that it's used? We already declared the variable as a pointer, we don't need to be reminded of that fact at every line.

It matters when you have things that imitate pointers (e.g. smart pointers). Those will have their own members, separate from the pointee's members, so ptr.foo could refer to the smart pointer's members or the pointee's members.

SomeDude said this best. This is far the common case, and the language shouldn't force everyone to pay for this situation.
Apr 28 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Typos. Typos everywhere :S I'm sure you get my meaning.
Apr 28 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 28 April 2012 at 23:50:22 UTC, foobar wrote:
 On Saturday, 28 April 2012 at 21:02:25 UTC, H. S. Teoh wrote:
 * di files - a library should encapsulate all the info 
 required
 to use it. Java Jars, .Net assemblies and even old school; 
 Pascal
 units all solved this long ago.



 I agree with the general notion here. Whatever the actual 
 implementation details are, the API should be strongly tied to 
 the binary in order to insure consistency and ease of use. I 
 shouldn't need to worry if the header files match the binary 
 library. Regarding the human readable API - that's why we have 
 documentation for.

Mmm well the main reason I see using .di files, is cases when the input library/file/dll doesn't give you much or any information. like... most dll's today. There's also tools to strip that extra debugging and structure information from your output file, so if you distribute a binary only, you still need to include it's .h file or .di file. Cases where this would be far more relevant could be in systems that don't have a lot of room (mini-distros or recovery disks for example). I've seen a recovery disk distro with everything you needed 2 floppies disks. Only reason I don't use floppies anymore is the ones being made are crap and don't keep data where as 14 years ago I could accidentally put mine through the wash and still access it's contents. (Cheap bastards)
Apr 28 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 * foreach_reverse is essentially redudant at this point (not to 
 mention
 confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...
 * I hate C style struct initializers and would really like to 
 see them go, but
 for reasons that I don't understand, people actually use them 
 rather than using a proper constructor call,

For single structs I prefer D-style initialization. But take a look at this code, if you replace those C-style initializers with D-style, even using aliases to shorten the code to single letters, that data section becomes more noisy: http://rosettacode.org/wiki/Ray-casting_algorithm#D
 * As for features that add little value, the first one that 
 comes to mind is
 with. I think that I've used it all of once, and I don't think 
 that I've seen
 it in other people's code very often.

It's rather common in Pascal/Delphi programming. I use it now and then. For a case where it's very handy see here, with an enumeration: http://rosettacode.org/wiki/Stable_marriage_problem#Alternative_version
 It's hard to grep for (since with is
 used in comments quite often),

Try to search for "with(" or "with\s(", that are less common in normal text.
 * Increasingly, I don't like UFCS. I think that in most cases, 
 it complicates
 code for little value. And I _really_ don't like how it results 
 in people
 flipping chains of a(b(c(d(5)))) calls into something like 
 d(5).c().b.().a(). I
 think that it makes the code way harder to read.

For me it makes that kind of code way simpler to read...
 The code is completely backwards.

It means call d on 5, then call c on the result, then call b on the result, and then call a on the result. It's better than before :-) Bye, bearophile
Apr 28 2012
prev sibling next sibling parent reply ponce <spam spam.org> writes:
Le 28/04/2012 20:47, Walter Bright a écrit :
 What's your list?

- builtin complex types (I don't _need_ be able to write "4 + 5i") - builtin associative arrays - some builtin properties like arr.sort - lazy, I use it only for logging - foreach_reverse, never used it - comma operator: when do you ever need it? - in operator Other than that, as a user I can't say having a lot of features is a big problem, it's a major selling point.
Apr 28 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-04-2012 03:20, ponce wrote:
 Le 28/04/2012 20:47, Walter Bright a écrit :
 What's your list?

- builtin complex types (I don't _need_ be able to write "4 + 5i")

+1.
 - builtin associative arrays
 - some builtin properties like arr.sort

+1, and .reverse. I'm also against .dup and .idup being properties, but these don't modify the array in place, so I take less issue with them.
 - lazy, I use it only for logging

lazy is horribly broken in many ways. Try to make a lazy value where the producing delegate is pure. (Hint: You can't.)
 - foreach_reverse, never used it
 - comma operator: when do you ever need it?

I've never used it intentionally, ever, but have been bitten in the ass countless times because of it.
 - in operator

Disagree. However, I do think it needs to made more useful (for instance, I simply don't understand why I can't use in to test for existence in an array).
 Other than that, as a user I can't say having a lot of features is a big
 problem, it's a major selling point.

-- - Alex
Apr 29 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 03:41, Jesse Phillips wrote:
 On Sunday, 29 April 2012 at 20:50:02 UTC, Alex Rønne Petersen wrote:

 - in operator

Disagree. However, I do think it needs to made more useful (for instance, I simply don't understand why I can't use in to test for existence in an array).

Complexity of the operation. in on an array is not nearly the same as with an associative array.

I know, but it's very intuitive still; see Python. -- - Alex
Apr 30 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 06:44, SomeDude wrote:
 On Tuesday, 1 May 2012 at 02:26:53 UTC, Alex Rønne Petersen wrote:
 On 01-05-2012 03:41, Jesse Phillips wrote:
 Complexity of the operation. in on an array is not nearly the same as
 with an associative array.

I know, but it's very intuitive still; see Python.

And that's why it's somewhat dangerous. Because it's so easy to use, someone that doesn't pay enough attention may overlook the fact that he is not using the right data structure. If he often has to do that more than once, he is using the wrong tool for the job. I agree it would be syntaxically nice, but I worry giving this syntactic sugar for what's a for loop with lots of comparisons isn't such a good idea. And the comparisons themselves are subject to caution. If for instance it's an array of floats, or some custom objects, it's very unlikely that you are going to compare bit by bit. So basically, this would be useful only for integers and chars.

1) So because some people might use a feature incorrectly due to lack of knowledge in algorithms and data structures, we should cripple the language? 2) The same holds true for AAs keyed by floats. -- - Alex
May 01 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 16:41, SomeDude wrote:
 On Tuesday, 1 May 2012 at 14:31:25 UTC, Alex Rønne Petersen wrote:
 1) So because some people might use a feature incorrectly due to lack
 of knowledge in algorithms and data structures, we should cripple the
 language?

It's not crippling the language. Nothing prevents you from writing a loop. Or using a library find function that does the same thing. But the name "find" gives you a hint that it's not magical and that it has a cost, while with "if( foo in bar)", it is too easy to forget that we are actually potentially performing an O(n) operation. In an AA, the 'in' keyword performs a O(1) operation, so that's ok to use it as a syntactic sugar.

No, it is not an O(1) operation, it is *close* to O(1) (as much sense as that statement can make). I don't know why you associate any particular complexity with 'in' in the first place. And I do think we're crippling the language, considering Python (and probably other languages) has had this feature since forever. I'm seriously worried. It seems to me like we're trying to cater to people who can't reason about the types in their program and the complexities of performing various operations on them. Since when did algorithmic complexity become a reason to take away syntax sugar? -- - Alex
May 01 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/2/12 6:15 AM, Tobias Pankrath wrote:
 No, it is not an O(1) operation, it is *close* to O(1) (as much sense
 as that statement can make). I don't know why you associate any
 particular complexity with 'in' in the first place. And I do think
 we're crippling the language, considering Python (and probably other
 languages) has had this feature since forever.

 I'm seriously worried. It seems to me like we're trying to cater to
 people who can't reason about the types in their program and the
 complexities of performing various operations on them. Since when did
 algorithmic complexity become a reason to take away syntax sugar?

+1 I do argee. opIn is handy for arrays, too. That the complexity would be linear and thus it should be disallowed is not a valid argument in my opinion, because with the exact same argument you could kick std.algorithm.find out of phobos. It is just obvious to every trained programmer that finding an element in an unordered list takes O(n).

The problem here is making complexity an implementation detail of a uniform interface (e.g. over hashes and linear containers). That is fail. Andrei
May 02 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/02/2012 04:01 PM, Andrei Alexandrescu wrote:
 On 5/2/12 6:15 AM, Tobias Pankrath wrote:
 No, it is not an O(1) operation, it is *close* to O(1) (as much sense
 as that statement can make). I don't know why you associate any
 particular complexity with 'in' in the first place. And I do think
 we're crippling the language, considering Python (and probably other
 languages) has had this feature since forever.

 I'm seriously worried. It seems to me like we're trying to cater to
 people who can't reason about the types in their program and the
 complexities of performing various operations on them. Since when did
 algorithmic complexity become a reason to take away syntax sugar?

+1 I do argee. opIn is handy for arrays, too. That the complexity would be linear and thus it should be disallowed is not a valid argument in my opinion, because with the exact same argument you could kick std.algorithm.find out of phobos. It is just obvious to every trained programmer that finding an element in an unordered list takes O(n).

The problem here is making complexity an implementation detail of a uniform interface (e.g. over hashes and linear containers). That is fail. Andrei

The interface is different: void main(){ int[] a = [0,0,0]; a[2] = 3; assert(2 !in a); } vs. void main(){ int[int] aa; aa[2] = 3; assert(2 in aa); }
May 02 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/2/12 10:20 AM, Timon Gehr wrote:
 The interface is different:

 void main(){
 int[] a = [0,0,0];
 a[2] = 3;
 assert(2 !in a);
 }

 vs.

 void main(){
 int[int] aa;
 aa[2] = 3;
 assert(2 in aa);
 }

The syntactic interface is the same. That would be the semantic interface, which makes the idea twice as bad. Andrei
May 02 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/02/2012 05:25 PM, Andrei Alexandrescu wrote:
 On 5/2/12 10:20 AM, Timon Gehr wrote:
 The interface is different:

 void main(){
     int[] a = [0,0,0];
     a[2] = 3;
     assert(2 !in a);
 }

 vs.

 void main(){
     int[int] aa;
     aa[2] = 3;
     assert(2 in aa);
 }

The syntactic interface is the same.

Encapsulation of complexity is a problem if it is not obvious to the programmer. I am not sure it can even be called such if the semantics is different.
 That would be the semantic interface, which makes the idea twice as bad.

 Andrei

I tend to agree, but I think that the two points are mutually exclusive.
May 02 2012
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 19:09, Jonathan M Davis wrote:
 On Tuesday, May 01, 2012 16:31:25 Alex Rønne Petersen wrote:
 1) So because some people might use a feature incorrectly due to lack of
 knowledge in algorithms and data structures, we should cripple the language?

If in is not restricted to a particular level Big-O complexity, then you cannot safely use it in generic code. That's why all of the functions in std.container give their Big-O complexity.

I don't think 'in' is actually used in any generic code (other than code specifically written for AAs, in which it *does* have a specific complexity in any case). I know I wouldn't use 'in' in truly generic code in any case, exactly because it has no defined complexity (even today; it's overloadable just like most other binary operators).
 In C++ [] is supposed to be O(log n) at worst. I would expect it to be the
 same in D, and since in is doing essentially the same operation, I would
 expect it to have the same Big-O complexity.

This is a good point, but not one I would subscribe to; it only holds true if you consider 'in' to be an operation purely limited to AAs. But this is already not the case given that it can be overloaded. So, I don't think that it having different complexity for arrays is a big deal. Personally, I consider 'in' to be syntax sugar for the language user. To me, it does not seem like a feature that a library of generic algorithms should be using at all.
 No, nothing is stopping a programmer from giving it horrible complexity, but
 the standard library and language should _definitely_ stick to O(log n) worst
 case for in and []. It would be a disaster for generic algorithms if in worked
 on normal arrays, because it would not be possible to maintain the required
 Big-O complexity.

I agree that any overload of [] and 'in' that Phobos does should stick to that constraint when possible (I say when possible, because sometimes innovative uses of these operators can't stick to this rather strict and mundane constraint; consider for example interaction with a database or what do I know...). But again, I don't think 'in' is something a generic algorithm should be using. We have the functions in std.algorithm and std.container if we need to write generic code. Also, I don't think language design should be *too* biased by the standard library's preferences. Not everyone agrees with Phobos conventions and we have to respect that IMHO. Just because it's a standard library doesn't mean that it should dictate users of the language who don't use the standard library.
 - Jonathan M Davis

-- - Alex
May 01 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Alex Rønne Petersen:

 - lazy, I use it only for logging

lazy is horribly broken in many ways.<

Sometimes I use std.exception.enforce(), that uses lazy. Bye, bearophile
Apr 29 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Sunday, 29 April 2012 at 20:50:02 UTC, Alex Rønne Petersen 
wrote:

 - in operator

Disagree. However, I do think it needs to made more useful (for instance, I simply don't understand why I can't use in to test for existence in an array).

Complexity of the operation. in on an array is not nearly the same as with an associative array.
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Tuesday, 1 May 2012 at 02:26:53 UTC, Alex Rønne Petersen 
wrote:
 On 01-05-2012 03:41, Jesse Phillips wrote:
 Complexity of the operation. in on an array is not nearly the 
 same as
 with an associative array.

I know, but it's very intuitive still; see Python.

And that's why it's somewhat dangerous. Because it's so easy to use, someone that doesn't pay enough attention may overlook the fact that he is not using the right data structure. If he often has to do that more than once, he is using the wrong tool for the job. I agree it would be syntaxically nice, but I worry giving this syntactic sugar for what's a for loop with lots of comparisons isn't such a good idea. And the comparisons themselves are subject to caution. If for instance it's an array of floats, or some custom objects, it's very unlikely that you are going to compare bit by bit. So basically, this would be useful only for integers and chars.
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Tuesday, 1 May 2012 at 14:31:25 UTC, Alex Rønne Petersen 
wrote:
 1) So because some people might use a feature incorrectly due 
 to lack of knowledge in algorithms and data structures, we 
 should cripple the language?

It's not crippling the language. Nothing prevents you from writing a loop. Or using a library find function that does the same thing. But the name "find" gives you a hint that it's not magical and that it has a cost, while with "if( foo in bar)", it is too easy to forget that we are actually potentially performing an O(n) operation. In an AA, the 'in' keyword performs a O(1) operation, so that's ok to use it as a syntactic sugar.
May 01 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 1 May 2012 at 14:41:43 UTC, SomeDude wrote:
 On Tuesday, 1 May 2012 at 14:31:25 UTC, Alex Rønne Petersen 
 wrote:
 1) So because some people might use a feature incorrectly due 
 to lack of knowledge in algorithms and data structures, we 
 should cripple the language?

It's not crippling the language. Nothing prevents you from writing a loop. Or using a library find function that does the same thing. But the name "find" gives you a hint that it's not magical and that it has a cost, while with "if( foo in bar)", it is too easy to forget that we are actually potentially performing an O(n) operation. In an AA, the 'in' keyword performs a O(1) operation, so that's ok to use it as a syntactic sugar.

I remember this was the argument Andrei also came up. Still can't make any sense out of it. If someone have some detailed reference please share! If you have it just for a niche usage, why do you have it at all? With UFCS "bar.contains(foo)" precise enough. You can make same argument for every operator in any language if you have operator overloading. And it would be against operator overloading, not particularly "in". -- Didn't know "http://forum.dlang.org/" adopted that unreadable/annoying to no end captchas.
May 01 2012
prev sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 No, it is not an O(1) operation, it is *close* to O(1) (as much 
 sense as that statement can make). I don't know why you 
 associate any particular complexity with 'in' in the first 
 place. And I do think we're crippling the language, considering 
 Python (and probably other languages) has had this feature 
 since forever.

 I'm seriously worried. It seems to me like we're trying to 
 cater to people who can't reason about the types in their 
 program and the complexities of performing various operations 
 on them. Since when did algorithmic complexity become a reason 
 to take away syntax sugar?

+1 I do argee. opIn is handy for arrays, too. That the complexity would be linear and thus it should be disallowed is not a valid argument in my opinion, because with the exact same argument you could kick std.algorithm.find out of phobos. It is just obvious to every trained programmer that finding an element in an unordered list takes O(n).
May 02 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Apr 28, 2012 at 04:56:52PM -0700, Jonathan M Davis wrote:
[...]
 One _big_ difference between D and C++ as far as complexity goes is
 that in C++, a _lot_ of the complexity comes from weird things in the
 language and knowing about how certain things can go horribly wrong
 (e.g. I can never remember all of the details on how horribly broken
 multiple inheritence is). 

Ugh. C++ multiple inheritance is a labyrinth, nay, a veritable minefield of subtle tripwires, inconvenient limitations, and a source of hair-tearing headaches. It's one of the bigger problems with C++'s OO implementation. Java's idea of single inheritance, multiple interfaces is a much better concept.
 It's frequently not an issue of knowing how to do things in the
 language but rather an issue of knowing what weird side effects an
 problems happen with certain stuff. With D, on the other hand, the
 complexity tends to be in just knowing what all of the features are
 and what they can do.

Except is() expressions, which appear to be totally arbitrary to me. As far as I'm concerned, it's just "memorize these bunch of arbitrary special rules".
 The only feature that comes to mind as probably being overly complex
 is is expressions, but that complexity can really come in handy
 sometimes.  std.traits should probably do more to alleviate the need
 for is expressions though so that odds of needing some of the more
 complicated stuff are lessened.

Needing to rely on std.traits is backwards, IMO. It's the compiler that knows all this stuff about types, why should we need to consult a library to get at the information? But anyway, the *functionality* of is-expressions are very useful, and, I'd argue, necessary. It's just that the syntax is atrocious and needs fixing.
 * As for redundant features, the first one that really comes to mind
 is WYSIWYG string literals. There are what, 4 different types of
 delimiters for string literals?

Only 4? I thought there were more. Last I looked, there were like 6 separate cases.
 I don't even remember all of the options. I just always use ` if I
 don't want any escaping in string literal and " if I do. The others
 may be valuable enough to have in some contexts, but I _never_ use
 them.

Yeah, I agree we should merge some of the string literal syntaxes. Some of them are useful (I'm a sucker for heredoc syntax) but currently it seems like just way too many options for something that should be really straightforward. [...]
 * I hate C style struct initializers and would really like to see them
 go, but for reasons that I don't understand, people actually use them
 rather than using a proper constructor call, so I doubt that we could
 get rid of them without a fair bit of complaining. I think that
 they're completely redundant and very _un_D.

It's annoying to have to write a constructor whose only purpose is to copy arguments into field members. Many uses of structs don't need the encapsulation that ctors were intended for.
 * There seem to be too many ways to do variadic functions. We have to
 allow C style variadics for extern(C), but having 3 of our own seems
 like a bit much.  Variadic templates are generally all that we need.
 The others don't seem necessary for the most part. But unfortunately,
 they should probably be left in so that classes can use them with
 virtual functions, since they can't use templates.

IMO we should unify variadic syntax into one (or perhaps leave the C variadics separate, since they're just for compatibility with C), and let the compiler implement each appropriately for the given context. [...]
 * Increasingly, I don't like UFCS. I think that in most cases, it
 complicates code for little value. And I _really_ don't like how it
 results in people flipping chains of a(b(c(d(5)))) calls into
 something like d(5).c().b.().a(). I think that it makes the code way
 harder to read. The code is completely backwards. But I appear to be
 in the minority with that opinion. I also don't like how it creates so
 many ways to write exactly the same code. It harms readibility. But as
 much as I dislike many of the applications of UFCS, it _does_ appear
 to be quite popular. And upon occasion, it may be useful, but I _am_
 wishing that we hadn't added it.

Strange, I like it a lot because unifying function calls makes it very easy to write generic code without sprinkling static ifs everywhere. [...]
 Overall, I think that D's feature set is fairly solid. It's mostly
 just the implementation of said features which is a problem - though
 some minor tweaks are probably in order (e.g. as Bearophile suggests,
 make it so that adjacent string literals don't concatenate).

I thought adjacent string lits have been deprecated or no longer supported? Personally I like it; it lets you format long literals over multiple lines without needing a ~ in between. And also, recently I found this annoyance: throw new Exception("A very long message (%s) that is "~ "broken across multiple (%d) lines".format(msg,count)); This doesn't work because ~ has lower precedence than ., so you need extra parentheses around the strings: throw new Exception(("A very long message (%s) that is "~ "broken across multiple (%d) lines").format(msg,count)); Whereas being able to concatenate adjacent literals would've been this a lot more readable. T -- I don't trust computers, I've spent too long programming to think that they can get anything right. -- James Miller
Apr 28 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 It's annoying to have to write a constructor whose only purpose 
 is to copy arguments into field members.

This is not needed in D for structs. Try it.
 I thought adjacent string lits have been deprecated or no longer
 supported?

Walter accepted to deprecate it lot of time ago, but it's not implemented yet.
 Personally I like it; it lets you format long literals over 
 multiple lines without needing a ~ in between.

If you write an array literal with many strings inside, and you forget a comma, you get less strings, silently. This is a source of real bugs. C# too disallows this, I think.
 And also, recently I found this annoyance:

Right, the precedence of the ~ operator different from the precedence of the invisible space operator. This causes some disadvantages. But I think the advantages in gained correctness are more important. Bye, bearophile
Apr 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, April 28, 2012 18:24:20 H. S. Teoh wrote:
 * I hate C style struct initializers and would really like to see them
 go, but for reasons that I don't understand, people actually use them
 rather than using a proper constructor call, so I doubt that we could
 get rid of them without a fair bit of complaining. I think that
 they're completely redundant and very _un_D.

It's annoying to have to write a constructor whose only purpose is to copy arguments into field members. Many uses of structs don't need the encapsulation that ctors were intended for.

You don't have to. If you have struct S { int field1; float field2; string field3; } then you can do auto s = S(5, 7.2, "hello"); The ability to do S s = {5, 7.2, "hello"}; gains you _nothing_. - Jonathan M Davis
Apr 28 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 29 April 2012 at 01:06:54 UTC, bearophile wrote:
 * I hate C style struct initializers and would really like to 
 see them go, but
 for reasons that I don't understand, people actually use them 
 rather than using a proper constructor call,

For single structs I prefer D-style initialization. But take a look at this code, if you replace those C-style initializers with D-style, even using aliases to shorten the code to single letters, that data section becomes more noisy: http://rosettacode.org/wiki/Ray-casting_algorithm#D

I have one source file called staticdata.d; Here immutable global data is stored. It's literally pages and pages of data and i only using static this() when building an AA. //excerpt: /NP and VT aliases. immutable SubRecordParts subParts[] = [ {"AADT", "", 16, [ //alchemy (apparatus) NP(VT.ranged_32, "Apparatus"), NP(VT.float_32, "Quality"), NP(VT.float_32, "Weight"), NP(VT.i_32, "uses")]}, {"AODT", "", 24, [ //armor NP(VT.ranged_32, "Armor Body Type"), NP(VT.float_32, "Weight"), NP(VT.i_32, "Value"), NP(VT.i_32, "Health"), NP(VT.i_32, "Enchant Points"), NP(VT.i_32, "Armour")]}, {"BKDT", "", 20, [ //book NP(VT.float_32, "Weight"), NP(VT.i_32, "Value"), NP(VT.i_32, "isScroll"), NP(VT.ranged_32, "Skill ID"), NP(VT.i_32, "Enchantment points")]}]; Would you really force me to use fully named and qualified for every element? More verbose but helps not at all. immutable SubRecordParts subParts[] = [ SubRecordParts("AADT", "", 16, [ //alchemy (apparatus) NotePart(ValueType.ranged_32, "Apparatus"), NotePart(ValueType.float_32, "Quality"), NotePart(ValueType.float_32, "Weight"), NotePart(ValueType.i_32, "uses")]), SubRecordParts("AODT", "", 24, [ //armor NotePart(ValueType.ranged_32, "Armor Body Type"), NotePart(ValueType.float_32, "Weight"), NotePart(ValueType.i_32, "Value"), NotePart(ValueType.i_32, "Health"), NotePart(ValueType.i_32, "Enchant Points"), NotePart(ValueType.i_32, "Armour")]), SubRecordParts("BKDT", "", 20, [ //book NotePart(ValueType.float_32, "Weight"), NotePart(ValueType.i_32, "Value"), NotePart(ValueType.i_32, "isScroll"), NotePart(ValueType.ranged_32, "Skill ID"), NotePart(ValueType.i_32, "Enchantment points")]) ];
Apr 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 03:06:53 bearophile wrote:
 * Increasingly, I don't like UFCS. I think that in most cases,
 it complicates
 code for little value. And I _really_ don't like how it results
 in people
 flipping chains of a(b(c(d(5)))) calls into something like
 d(5).c().b.().a(). I
 think that it makes the code way harder to read.

For me it makes that kind of code way simpler to read...
 The code is completely backwards.

It means call d on 5, then call c on the result, then call b on the result, and then call a on the result. It's better than before :-)

I know that you find easier to read. A number of people do. But it is just so backwards in comparison to how stuff normally works, that it hurts my brain. But I've done enough functional programming that I find something likea(b(c(d(5)))) to be completely straightforward, and for some reason not everyone does. And while I _never_ intend to use UFCS in this manner, I'm going to forever have to read the code of others who do, which I find to be a major negative. But regardless of my personal opinion on the matter, it's clear that enough people like UFCS that it's not going anywhere unless something seriously wrong is found with it which makes it untenable. - Jonathan M Davis
Apr 28 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 29 April 2012 at 01:36:10 UTC, Jonathan M Davis wrote:
 On Saturday, April 28, 2012 18:24:20 H. S. Teoh wrote:
 then you can do

 auto s = S(5, 7.2, "hello");

 The ability to do

 S s = {5, 7.2, "hello"};

 gains you _nothing_.

Depends on how many levels you are using on a array. I've noted in another part of this topic where I have pages and pages of the data. Forcing me to qualify it with a name when the compiler/structure already knows just seems like an annoyance. True it removes the {}'s, but I think I have 3 levels of deep. S[] s = [S(),S(),S()]; vs S[] s = [{},{},{}]; If they are more complex, then indenting and separation makes sense. And the size of the name I don't want to have to Alias my structures to something tiny and a little obfuscate in order to keep it compact and simple. That's my thoughts anyways. If the language later disallows it, I'll have to change my code to compensate for it.
Apr 28 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/29/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 struct S
 {
     int field1;
     float field2;
     string field3;
 }
 then you can do

 auto s = S(5, 7.2, "hello");

 The ability to do

 S s = {5, 7.2, "hello"};

 gains you _nothing_.

That's not really the benefit of those initializers. This is: S[] arr = [{field2 = 1.0}, {field2 = 0.5}]; It's a real benefit when unittesting because it allows me to quickly create variables with some interesting state which I can then test.
Apr 28 2012
prev sibling next sibling parent "Francois Chabot" <francois.chabot.dev gmail.com> writes:
 - properties - another incredibly convenient feature. I think a 
 more sexy implementation of properties are in order, but the 
 construct is great. It would be nice to have properties as a 
 language type, rather than a attribute:

To me, properties are much more than a convenience. The important part of it comes from its existence, not its usage. Quite simply, having properties mean that using public member variables does not break encapsulation (as long as having them part of the public interface is intentional). Without properties, you MUST write accessors for all of them on the off chance that you might want to refactor/delegate them in the future. This adds a huge amount of boilerplate code that ends up wasted time 98% of the time. In short, properties existing, even if not used, end up improving both my efficiency and the legibility of my code.
Apr 28 2012
prev sibling next sibling parent "Francois Chabot" <francois.chabot.dev gmail.com> writes:
 What's your list?

- The is expressions are confusing as hell, and it seems to me that it's serving a purpose that should be handled by __traits (which has its own set of issues in my mind, but is a solid idea) - On the subject, as much as I love __traits(), its dumping grounds nature is problematic. It should be limited to accessing traits of types, or changed to a more representative name. It's not redundant or anything, but is prone to bloating by its design. - I am on the version hate boat. To me, it's redundant with static if(). - as many have said, the comma operator is problematic by nature and should probably go. I haven't been into D for very long, so I'll probably run into more stuff eventually, but that's what comes off the top of my head...
Apr 28 2012
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 28 Apr 2012 14:03:26 -0700, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:

 On Sat, Apr 28, 2012 at 09:58:02PM +0200, foobar wrote:
 [...]
 D has a lot of ad-hock features which make the language
 needlessly large and complex. I'd strive to replace these with
 better general purpose mechanisms.

 My list:
 * I'd start with getting rid of foreach completely. (not just
 foreach_reverse). This is nothing more than a fancy function with
 a delegate parameter.

I disagree. Having a dedicated foreach construct allows the compiler to optimize away the delegate in certain cases. I wouldn't want to incur the cost of creating and passing a delegate in something as simple as foreach (i; 0..100), for example.
 * enum - enum should be completely redesigned to only implement
 what it's named after: enumerations.

Actually, I rather like the enum idiom of declaring compile-time constants. Though it could do with a renaming to something more befitting.
 * version - this does not belong in a programming language. Git
 is a much better solution.

This is an interesting idea. But using separate git branches just for having versioned code seems a bit like total overkill... plus a maintenance nightmare since you have to continue pull and merge changes to every porting branch every time development happens. Whereas having everything represented in source means that whoever writes a new feature is also responsible for making it work with whatever versions are currently out there. After-the-fact fixes are always painful.
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; Pascal
 units all solved this long ago.

I proposed a while ago that .di files should be replaced by something better: omit ALL function bodies, template bodies, private members, etc., and just keep the "real" public API in the human-readable part of the file. Function and template bodies should be kept in as a binary blob readable by the compiler (which obviously needs to know them otherwise it won't be able to expand templates).

I have written code that will do just that. You can check it out here: https://github.com/LightBender/dmd.git. It builds both the DRuntime and Phobos perfectly, however, the Phobos makefile has not yet been updated to generate DI files. However, Phobos uses the Druntime DI files for it's build.
 (Yes the binary blob can be reverse-engineered, but so can executables,
 so it's a moot point. We're not trying to write cryptographic security
 here, but it's nice to separate what the compiler needs to know vs. what
 the user of a library needs to know.)


 * This is a big one: get rid of *all* current compile time
 special syntax. It should be replaced by a standard compilation
 API and the compiler should be able to use plugins/addons. This
 would reduce the size of the language to half of its current
 size, maybe even more.

I have to disagree here. CTFE and compile-time features is a major reason I like D. I argue rather that compile-time features should be *improved*. The current situation is good, but not quite there yet. It can be made better. T

-- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Apr 28 2012
prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 28 Apr 2012 15:39:49 -0400
schrieb "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com>:

 "q66" <quaker66 gmail.com> wrote in message 
 news:ihqjguujvoukhlqcwkyi forum.dlang.org...
 - Phobos is too fat - it needs to shrink to just a few core modules, 
 others being distributed via some system like CPAN for Perl
 - Properties - they're kinda broken at this point and the value is 
 questionable
 -  trusted  system
 - Exception handling - a lot of runtime, questionable value

That's just craziness!

Madness even! AAs are soon mostly in the library and that's a good trade-off; trusted system needs to be there as long as there is safe; exception handling - some people rely on it heavily. See it as the easy way to error out of a function that doesn't normally return anything and cascade up several calls, while being able to release resources in each. I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly. I can agree on the rest. -- Marco
Apr 28 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Marco Leise" <Marco.Leise gmx.de> wrote in message 
news:20120429075404.121a5a46 marco-leise...
 I don't know about Phobos. Some batteries included are nice and help the 
 popularity. When it comes to bindings to third party products with many 
 alternatives, like databases, I'd say one should cut it there definitly.

Yea, it's a tradeoff either way. Once we have a mature "D CPAN", there will be less reason to pack things into Phobos. But until that actually happens, a "batteries included"-style std lib is necessary. And of course, like you say, there are likely things that just aren't appropriate for the std lib either way.
Apr 28 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
 My list:
 * I'd start with getting rid of foreach completely. (not just 
 foreach_reverse).


 C++ was criticized for a long time for NOT having foreach in 
 the language. Now they have 
 http://www2.research.att.com/~bs/C++0xFAQ.html#for. Also people 
 were so desperate to gave it that even this 
 http://www.boost.org/doc/libs/1_49_0/doc/html/foreach.html was 
 considered a nice addition to boost (and still part of it).

 Obviously somehow you want to go into the opposite direction. 
 Beats me.

If it simplifies code, makes it easier, and is more consistent, having it is better than not having it. Like walter said in one of the recent videos (going native 2012) regarding having an assembler in a language: 'When you need it, you got to have it'. True most features can be re-written as work arounds, but if you don't have to then why insist on it? Backtracking by removing key features which make the language pleasant may throw us back into the C and C++ days. Yes you can do full memory management yourself, and use pointers and pass it's size to functions. We have fat pointers, so why insist on backtracking? At the worst case if it isn't breaking the language leave it alone. If you have good reasons for it, explain them in detail. At best those of us who know better will laugh and move on.
Apr 28 2012
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.04.2012 20:47, schrieb Walter Bright:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

- two different ways of creating function pointers is confusing (function and delegate) I understand the reasoning, but makes one think all the time when to use what. - sometimes D code looks like template and mixins gone mad While I do appreciate the power, it can be quite confusing to try to understand what the code does. Specially with the lack of support in mixin's debugging - __traits should be given a proper name It looks out of place in regard with the rest of the language, by making use of the underscores - AA should be a library type I am on the C++ and Scala camp where the language should be extendable via the library - misuse of enum to declare constants I prefer that the use of const would be possible - conditional compilation is hard to follow without syntax highlighting Other languages with conditional compilation make it easier to follow what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada - unit tests I would rather have them as a library. While it is fun to discuss what we like and not like, I vote that priority should be given to make the language stable and have better tooling. We need to have safer languages with native code generation for systems programming in the mainstream OS, that take us away from the buffer overflow exploits and dagling pointers legacy that C and C++ brought upon us. Someone that does not know D and sees the amount of bugs still existing, or this type of discussions, will run away to Go or some future version of C#/Spec#/Bartok, or back to whatever he/she was using before. I don't agree D is complex, any language that aims to be used in large application domains, needs a certain set of abstractions. If it does not support them, it is condemmend to keep getting new features until it turns in what the language designers were fighting against. -- Paulo
Apr 28 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 08:31 AM, Paulo Pinto wrote:
 Am 28.04.2012 20:47, schrieb Walter Bright:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

- two different ways of creating function pointers is confusing (function and delegate) I understand the reasoning, but makes one think all the time when to use what.

'delegate' is more powerful, 'function' is more efficient. If you don't want to think about it, just use 'delegate'. I'd rather see 'function' implicitly convert to 'delegate' than to have it gone. D can be used for systems programming after all!
 - sometimes D code looks like template and mixins gone mad
 While I do appreciate the power, it can be quite confusing to try
 to understand what the code does. Specially with the lack of support
 in mixin's debugging

pragma(msg, ...) ?
 - misuse of enum to declare constants
 I prefer that the use of const would be possible

const infects the type and const-qualified data can exist at runtime, so it is not possible.
 - conditional compilation is hard to follow without syntax highlighting
 Other languages with conditional compilation make it easier to follow
 what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada

That is not a language issue.
 While it is fun to discuss what we like and not like, I vote that
 priority should be given to make the language stable and have better
 tooling.

 We need to have safer languages with native code generation for systems
 programming in the mainstream OS, that take us away from the buffer
 overflow exploits and dagling pointers legacy that C and C++ brought
 upon us.

 Someone that does not know D and sees the amount of bugs still existing,
 or this type of discussions, will run away to Go or some future version
 of C#/Spec#/Bartok, or back to whatever he/she was using before.

 I don't agree D is complex, any language that aims to be used in large
 application domains, needs a certain set of abstractions. If it does not
 support them, it is condemmend to keep getting new features until it
 turns in what the language designers were fighting against.

I agree with this section.
Apr 29 2012
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 29.04.2012 10:42, schrieb Timon Gehr:
 On 04/29/2012 08:31 AM, Paulo Pinto wrote:
 Am 28.04.2012 20:47, schrieb Walter Bright:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

- two different ways of creating function pointers is confusing (function and delegate) I understand the reasoning, but makes one think all the time when to use what.

'delegate' is more powerful, 'function' is more efficient. If you don't want to think about it, just use 'delegate'. I'd rather see 'function' implicitly convert to 'delegate' than to have it gone. D can be used for systems programming after all!

That is what I mean. The compiler could make the distinction between function and delegate itself. I am not arguing to remove the feature, rather to have the compiler check it for me. Surely it can see if I am passing the delegate to D code or extern C/C++ code and act accordingly.
 - sometimes D code looks like template and mixins gone mad
 While I do appreciate the power, it can be quite confusing to try
 to understand what the code does. Specially with the lack of support
 in mixin's debugging

pragma(msg, ...) ?

Too low level?
 - misuse of enum to declare constants
 I prefer that the use of const would be possible

const infects the type and const-qualified data can exist at runtime, so it is not possible.

Yeah, but it brings me back bad memories from the early days, when C++ compilers did not fully support C++98, and we had to resort to the enum trick to create constants.
 - conditional compilation is hard to follow without syntax highlighting
 Other languages with conditional compilation make it easier to follow
 what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada

That is not a language issue.

How come? In the languages mentioned above, the conditional compilation stands out in clear text that is doing something at compile time. In D you need to be aware which statements are compile time and which are not. Not a big deal to argue about, but easy trap for D newbies. -- Paulo
Apr 29 2012
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 29.04.2012 15:24, schrieb David Nadlinger:
 On Sunday, 29 April 2012 at 12:41:37 UTC, Paulo Pinto wrote:
 I am not arguing to remove the feature, rather to have the compiler
 check it for me. Surely it can see if I am passing the delegate to D
 code or extern C/C++ code and act accordingly.

How would this work? Function pointers are only a single word in D code as well (and a single unconditional jump to that address) , whereas delegates are two words. What is if a function accepts a delegate, but a function pointer is passed? What is if a delegate is passed to a (possibly C) function – does the compiler automatically emit a thunk for that? David

Yes, that is what I had in mind. That is what is done in .NET as far as I am aware.
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 12:41:37 UTC, Paulo Pinto wrote:
 I am not arguing to remove the feature, rather to have the 
 compiler check it for me. Surely it can see if I am passing the 
 delegate to D code or extern C/C++ code and act accordingly.

How would this work? Function pointers are only a single word in D code as well (and a single unconditional jump to that address) , whereas delegates are two words. What is if a function accepts a delegate, but a function pointer is passed? What is if a delegate is passed to a (possibly C) function – does the compiler automatically emit a thunk for that? David
Apr 29 2012
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-04-2012 08:31, Paulo Pinto wrote:
 Am 28.04.2012 20:47, schrieb Walter Bright:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

- two different ways of creating function pointers is confusing (function and delegate) I understand the reasoning, but makes one think all the time when to use what. - sometimes D code looks like template and mixins gone mad While I do appreciate the power, it can be quite confusing to try to understand what the code does. Specially with the lack of support in mixin's debugging - __traits should be given a proper name It looks out of place in regard with the rest of the language, by making use of the underscores - AA should be a library type I am on the C++ and Scala camp where the language should be extendable via the library - misuse of enum to declare constants I prefer that the use of const would be possible - conditional compilation is hard to follow without syntax highlighting Other languages with conditional compilation make it easier to follow what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada - unit tests I would rather have them as a library.

D unit tests were never really useful for anything beyond single-library projects IMHO. They don't scale for large, real-world application projects with lots of libraries and executables.
 While it is fun to discuss what we like and not like, I vote that
 priority should be given to make the language stable and have better
 tooling.

 We need to have safer languages with native code generation for systems
 programming in the mainstream OS, that take us away from the buffer
 overflow exploits and dagling pointers legacy that C and C++ brought
 upon us.

 Someone that does not know D and sees the amount of bugs still existing,
 or this type of discussions, will run away to Go or some future version
 of C#/Spec#/Bartok, or back to whatever he/she was using before.

 I don't agree D is complex, any language that aims to be used in large
 application domains, needs a certain set of abstractions. If it does not
 support them, it is condemmend to keep getting new features until it
 turns in what the language designers were fighting against.

 --
 Paulo

-- - Alex
Apr 29 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 29/04/2012 22:54, Alex Rřnne Petersen a écrit :
 D unit tests were never really useful for anything beyond single-library
 projects IMHO. They don't scale for large, real-world application
 projects with lots of libraries and executables.

+1 A good std.unittest + attributes is probably a better approach.
Apr 29 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 20:03:44 H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 11:39:02PM +0200, deadalnix wrote:
 Le 29/04/2012 22:54, Alex R=C3=B8nne Petersen a =C3=A9crit :
D unit tests were never really useful for anything beyond
single-library projects IMHO. They don't scale for large, real-wor=



application projects with lots of libraries and executables.

+1 A good std.unittest + attributes is probably a better approach.

The only reason I actually write unittests for D code is because unittest{} is so convenient. If I had to import std.unittest, most likely my code will have no unittests at all. =20 I find that because unittest{} makes it so convenient to write unittests, it's just embarrassing to not write them. Which is kinda t=

 point, 'cos in my experience the act of writing a unittest automatica=

 makes you think about corner cases in the code you just wrote (or jus=

 about to write), which means there will be less bugs from the get-go.=

=20
 Also, unittest is just that: for _unit_ tests. If you start needing a=

 entire framework for them, then you're no longer talking about _unit_=

 tests, you're talking about module- or package-level testing framewor=

 and you should be using something more suitable for that, not unittes=

One common term for those is "component tests." Unit tests are for test= ing=20 individual functions and types, whereas component tests test inter-modu= le and=20 inter-program interactions. What D has with regards to unit tests works _very_ well for basic unit = tests=20 but does not attempt to support component tests at all beyond where uni= ttest=20 blocks could be used for the same purpose. The main place that D's unit= test=20 framework becomes problematic is when you need to run a subset of tests= - it's=20 designed to run everything at once. But compiling and running each modu= le=20 separately for unit tests allows you to control that through you build = system=20 or whatnot. As Walter has stated on several occasions, D's built-in unit testing fr= amework=20 is designed to be incredibly simple and easy so that they're so easy an= d=20 convenient to use that you have no excuse not to. If you want more comp= licated=20 unit testing frameworks, there's nothing stopping you from making your = own=20 like has to be done in other languges. For instance, cppunit and junit = aren't=20 built-in to their associated languages at all; they're 3rd party projec= ts. You=20 can do the same in D if you want fancier unit testing facilities. - Jonathan M Davis
Apr 29 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 05:12, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 20:03:44 H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 11:39:02PM +0200, deadalnix wrote:
 Le 29/04/2012 22:54, Alex Rønne Petersen a écrit :
 D unit tests were never really useful for anything beyond
 single-library projects IMHO. They don't scale for large, real-world
 application projects with lots of libraries and executables.

+1 A good std.unittest + attributes is probably a better approach.

The only reason I actually write unittests for D code is because unittest{} is so convenient. If I had to import std.unittest, most likely my code will have no unittests at all. I find that because unittest{} makes it so convenient to write unittests, it's just embarrassing to not write them. Which is kinda the point, 'cos in my experience the act of writing a unittest automatically makes you think about corner cases in the code you just wrote (or just about to write), which means there will be less bugs from the get-go. Also, unittest is just that: for _unit_ tests. If you start needing an entire framework for them, then you're no longer talking about _unit_ tests, you're talking about module- or package-level testing frameworks, and you should be using something more suitable for that, not unittest.

One common term for those is "component tests." Unit tests are for testing individual functions and types, whereas component tests test inter-module and inter-program interactions. What D has with regards to unit tests works _very_ well for basic unit tests but does not attempt to support component tests at all beyond where unittest blocks could be used for the same purpose. The main place that D's unit test framework becomes problematic is when you need to run a subset of tests - it's designed to run everything at once. But compiling and running each module separately for unit tests allows you to control that through you build system or whatnot. As Walter has stated on several occasions, D's built-in unit testing framework is designed to be incredibly simple and easy so that they're so easy and convenient to use that you have no excuse not to. If you want more complicated unit testing frameworks, there's nothing stopping you from making your own like has to be done in other languges. For instance, cppunit and junit aren't built-in to their associated languages at all; they're 3rd party projects. You can do the same in D if you want fancier unit testing facilities. - Jonathan M Davis

Except we can't do: test void myTest() { // ... } due to the current lack of annotations and discovery-based reflection. ;) *hint hint...* -- - Alex
Apr 29 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 05:34, Jonathan M Davis wrote:
 On Monday, April 30, 2012 05:20:21 Alex Rønne Petersen wrote:
 Except we can't do:

  test
 void myTest()
 {
       // ...
 }

 due to the current lack of annotations and discovery-based reflection. ;)

 *hint hint...*

What would that buy you? That's what unittest blocks are for. Yes, getting custom annotations would be great, and then you could use test for whatever you need it for, but unittest blocks are the test functions, so I'm not quite sure what test would buy you. You _could_ just put a particular string in a name though (e.g. start all unit test functions with test) and use compile- time reflection to find them if you really want to though (much as that isn't as nice as a user-defined attribute would be). - Jonathan M Davis

See my other reply to H. S. Teoh for why I'm not a fan of unittest blocks. -- - Alex
Apr 29 2012
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 30-04-2012 05:03, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 11:39:02PM +0200, deadalnix wrote:
 Le 29/04/2012 22:54, Alex Rřnne Petersen a écrit :
 D unit tests were never really useful for anything beyond
 single-library projects IMHO. They don't scale for large, real-world
 application projects with lots of libraries and executables.

+1 A good std.unittest + attributes is probably a better approach.

The only reason I actually write unittests for D code is because unittest{} is so convenient. If I had to import std.unittest, most likely my code will have no unittests at all. I find that because unittest{} makes it so convenient to write unittests, it's just embarrassing to not write them. Which is kinda the point, 'cos in my experience the act of writing a unittest automatically makes you think about corner cases in the code you just wrote (or just about to write), which means there will be less bugs from the get-go. Also, unittest is just that: for _unit_ tests. If you start needing an entire framework for them, then you're no longer talking about _unit_ tests, you're talking about module- or package-level testing frameworks, and you should be using something more suitable for that, not unittest. T

The problem with D's unit test support is that it doesn't integrate well into real world build processes. I usually have debug and release configurations, and that's it. No test configuration; not only does that over-complicate things, but it also isn't really useful. I want my unit testing to be exhaustive; i.e. I want to test my code in debug and release builds, because those are the builds people are going to be using. Not a test build. So, this means that writing unit tests inline is a no-go because that would require either always building with unit tests in all configurations (madness) or having a test configuration (see above). Given the above, I've resorted to having a "tester" executable which links in all libraries in my project and tests every module. This means that I have to write my unit tests inside this helper executable, making much of the gain in D's unittest blocks go away. And no, the fact that I link libraries into the helper executable doesn't mean that I can just write the unit tests in the libraries in the first place. Doing so would require building them twice: Once for the normal build and once for the "tester" executable. (And yes, build times matter when your project gets large enough, even in D.) -- - Alex
Apr 29 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 21:56:08 H. S. Teoh wrote:
 I wonder if dmd (or rdmd) should have a mode where it *only* compiles
 unittest code (i.e., no main() -- the resulting exe just runs unittests
 and nothing else).

It wouldn't make sense. It's nowhere near as bad as C++, but dmd has to recompile modules all the time unless you compile the entire program at once. When you run a build, every single module on the command line and all of the imported modules get compiled. Object code is generated only for those on the command line, but the others are still compiled. Any imported module which uses a .di file won't have as much to compile, and any templated code that doesn't get used in those modules won't get compiled, but there's still lots of recompilation going on if you compile your program incrementally. And D just isn't set up to compile only a portion of a module. - Jonathan M Davis
Apr 29 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 07:03 AM, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 21:56:08 H. S. Teoh wrote:
 I wonder if dmd (or rdmd) should have a mode where it *only* compiles
 unittest code (i.e., no main() -- the resulting exe just runs unittests
 and nothing else).

It wouldn't make sense. It's nowhere near as bad as C++, but dmd has to recompile modules all the time unless you compile the entire program at once. When you run a build, every single module on the command line and all of the imported modules get compiled.

Only the symbols that need to be analysed actually get analysed (eg. CTFE, instantiated templates.) The other symbols are merely parsed, and parsing is quite cheap.
 Object code is generated only for those on the
 command line, but the others are still compiled.

I think 'compiled' would imply that some output code is generated.
 Any imported module which
 uses a .di file won't have as much to compile,

There is no difference between .d files and .di files except that the compiler prefers the .di file for imports.
 and any templated code that
 doesn't get used in those modules won't get compiled,  but there's still lots
 of recompilation going on if you compile your program incrementally.

It depends on how much CTFE is performed on the module interface level.
 And D

DMD.
 just isn't set up to compile only a portion of a module.

 - Jonathan M Davis

If that is necessary then the module is too big.
Apr 30 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/30/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 On Sunday, April 29, 2012 21:56:08 H. S. Teoh wrote:
 I wonder if dmd (or rdmd) should have a mode where it *only* compiles
 unittest code (i.e., no main() -- the resulting exe just runs unittests
 and nothing else).


For RDMD you can do: version(unittest) { } else void main() { // regular code here } And then you can invoke rdmd with --unittest and --main to insert an empty main function when unittesting. Personally I put in a stub main so I don't depend on rdmd features like --main: version(unittest) { void main(string[] args) { } } // stub main else void main() { // regular code here }
Apr 29 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-30 05:16, Alex Rřnne Petersen wrote:
 On 30-04-2012 05:03, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 11:39:02PM +0200, deadalnix wrote:
 Le 29/04/2012 22:54, Alex Rřnne Petersen a écrit :
 D unit tests were never really useful for anything beyond
 single-library projects IMHO. They don't scale for large, real-world
 application projects with lots of libraries and executables.

+1 A good std.unittest + attributes is probably a better approach.

The only reason I actually write unittests for D code is because unittest{} is so convenient. If I had to import std.unittest, most likely my code will have no unittests at all. I find that because unittest{} makes it so convenient to write unittests, it's just embarrassing to not write them. Which is kinda the point, 'cos in my experience the act of writing a unittest automatically makes you think about corner cases in the code you just wrote (or just about to write), which means there will be less bugs from the get-go. Also, unittest is just that: for _unit_ tests. If you start needing an entire framework for them, then you're no longer talking about _unit_ tests, you're talking about module- or package-level testing frameworks, and you should be using something more suitable for that, not unittest. T

The problem with D's unit test support is that it doesn't integrate well into real world build processes. I usually have debug and release configurations, and that's it. No test configuration; not only does that over-complicate things, but it also isn't really useful. I want my unit testing to be exhaustive; i.e. I want to test my code in debug and release builds, because those are the builds people are going to be using. Not a test build. So, this means that writing unit tests inline is a no-go because that would require either always building with unit tests in all configurations (madness) or having a test configuration (see above). Given the above, I've resorted to having a "tester" executable which links in all libraries in my project and tests every module. This means that I have to write my unit tests inside this helper executable, making much of the gain in D's unittest blocks go away. And no, the fact that I link libraries into the helper executable doesn't mean that I can just write the unit tests in the libraries in the first place. Doing so would require building them twice: Once for the normal build and once for the "tester" executable. (And yes, build times matter when your project gets large enough, even in D.)

-- /Jacob Carlborg
Apr 30 2012
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 11:46, SomeDude wrote:
 On Monday, 30 April 2012 at 03:16:57 UTC, Alex Rønne Petersen wrote:
 The problem with D's unit test support is that it doesn't integrate
 well into real world build processes. I usually have debug and release
 configurations, and that's it. No test configuration; not only does
 that over-complicate things, but it also isn't really useful. I want
 my unit testing to be exhaustive; i.e. I want to test my code in debug
 and release builds, because those are the builds people are going to
 be using. Not a test build.

 So, this means that writing unit tests inline is a no-go because that
 would require either always building with unit tests in all
 configurations (madness) or having a test configuration (see above).

 Given the above, I've resorted to having a "tester" executable which
 links in all libraries in my project and tests every module. This
 means that I have to write my unit tests inside this helper
 executable, making much of the gain in D's unittest blocks go away.

 And no, the fact that I link libraries into the helper executable
 doesn't mean that I can just write the unit tests in the libraries in
 the first place. Doing so would require building them twice: Once for
 the normal build and once for the "tester" executable.

OK, that makes sense. What a test framework could do, although it's kind of ugly, is first copy the unittest() sections into separate test files, compile them and then link with the tested module code. You would keep the advantage of having test code close to source code, and still compile the real code without -unittest switch.
 (And yes, build times matter when your project gets large enough, even
 in D.)

Just for information, how big is your project (how many files), and how long does a full build take ? I have no idea how fast the compiler really is (is it GDC or DMD you are using ?).

I don't have a clone of my repo from where I am now, so I can't count, but it usually takes around ~30 seconds with DMD, ~2 minutes with GDC. -- - Alex
Apr 30 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-30 18:44, Iain Buclaw wrote:

 GCC backend has some 50+ passes it processes the generated AST through
 passed from GDC. Not to mention it only outputs assembly code.  So
 there is some overhead for calling AS to compile to object code
 (something that DMD just compiles straight to), and double overhead
 for calling LD to link the resultant binary/library.

DMD calls GCC which calls LD. Unless your using the -lib flag. -- /Jacob Carlborg
Apr 30 2012
prev sibling parent reply Don Clugston <dac nospam.com> writes:
On 08/05/12 09:56, Andrej Mitrovic wrote:
 On 4/30/12, Andrej Mitrovic<andrej.mitrovich gmail.com>  wrote:
 Personally my gripe with compilation times is that I get very used to
 having fast build times where I can go through an edit+compile+run
 cycle really fast, but after a while build times get slower

Also since 2.059 error reporting is *completely* broken. I have to wait 5 seconds just to get this error message itself to print to the screen: http://pastebin.com/y93GEPAf 500 lines of errors even though only the first line is an actual error. What in the actual fuck are all those other error messages? The only problem was this line in a main file: CppGen gen; and CppGen was undefined because I've missed an import. And if I remove the only import left (std.range), I get much less garbage but I still get unrelated errors: main.d(80): Error: undefined identifier CppGen D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template std.conv.toImpl does not match any function template declaration D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template std.conv.toImpl cannot deduce template function from argument types !(string)(long) D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template instance toImpl!(string) errors instantiating template loader\gcc.d(167): Error: template instance std.conv.to!(string).to!(long) error instantiating 2.058 error reporting worked fine, I don't know what someone did to screw this up so massively.

That bug was fixed in git not long after release. Unfortunately it seems that there are not enough people doing beta testing. As for why it happened -- previously the compiler used a hack to prevent the flood of error messages (and the hack didn't work properly in the case where errors were gagged, like in is(typeof()) ). Now it does it properly.
May 08 2012
parent Don Clugston <dac nospam.com> writes:
On 08/05/12 14:50, Andrej Mitrovic wrote:
 On 5/8/12, Don Clugston<dac nospam.com>  wrote:
 That bug was fixed in git not long after release.

I still get it with this version: http://d.puremagic.com/test-results/test_data.ghtml?dataid=180993 Same errors: http://pastebin.com/8uqgskHd

OK, looks like it's a different bug. Please put in bugzilla, with status of regression.
May 09 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 30/04/2012 05:03, H. S. Teoh a écrit :
 On Sun, Apr 29, 2012 at 11:39:02PM +0200, deadalnix wrote:
 Le 29/04/2012 22:54, Alex Rřnne Petersen a écrit :
 D unit tests were never really useful for anything beyond
 single-library projects IMHO. They don't scale for large, real-world
 application projects with lots of libraries and executables.

+1 A good std.unittest + attributes is probably a better approach.

The only reason I actually write unittests for D code is because unittest{} is so convenient. If I had to import std.unittest, most likely my code will have no unittests at all.

Is unittest on top of a function much more difficult ?
 I find that because unittest{} makes it so convenient to write
 unittests, it's just embarrassing to not write them. Which is kinda the
 point, 'cos in my experience the act of writing a unittest automatically
 makes you think about corner cases in the code you just wrote (or just
 about to write), which means there will be less bugs from the get-go.

Agreed.
 Also, unittest is just that: for _unit_ tests. If you start needing an
 entire framework for them, then you're no longer talking about _unit_
 tests, you're talking about module- or package-level testing frameworks,
 and you should be using something more suitable for that, not unittest.

Consider cases like checking if Liskov substitution principle is fallowed in a class hierarchy running the same unitest on various instantiations in that hierarchy. This is common need and still fall in the unittest bag.
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Alex Rønne Petersen:

 D unit tests were never really useful for anything beyond 
 single-library projects IMHO. They don't scale for large, 
 real-world application projects with lots of libraries and 
 executables.

I think D has to offers means to library writers to instrument the built-in unit-testing machinery, to allow the implementation of a good unit testing system. Bye, bearophile
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 20:54:11 UTC, Alex Rønne Petersen 
wrote:
 - unit tests
 I would rather have them as a library.

D unit tests were never really useful for anything beyond single-library projects IMHO. They don't scale for large, real-world application projects with lots of libraries and executables.

What's the problem ? What prevents you to put the unit tests in other modules if you don't want to put them with the code ?
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 11:39:02PM +0200, deadalnix wrote:
 Le 29/04/2012 22:54, Alex Rřnne Petersen a écrit :
D unit tests were never really useful for anything beyond
single-library projects IMHO. They don't scale for large, real-world
application projects with lots of libraries and executables.

+1 A good std.unittest + attributes is probably a better approach.

The only reason I actually write unittests for D code is because unittest{} is so convenient. If I had to import std.unittest, most likely my code will have no unittests at all. I find that because unittest{} makes it so convenient to write unittests, it's just embarrassing to not write them. Which is kinda the point, 'cos in my experience the act of writing a unittest automatically makes you think about corner cases in the code you just wrote (or just about to write), which means there will be less bugs from the get-go. Also, unittest is just that: for _unit_ tests. If you start needing an entire framework for them, then you're no longer talking about _unit_ tests, you're talking about module- or package-level testing frameworks, and you should be using something more suitable for that, not unittest. T -- Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 05:16:55AM +0200, Alex Rřnne Petersen wrote:
 On 30-04-2012 05:03, H. S. Teoh wrote:

Also, unittest is just that: for _unit_ tests. If you start needing
an entire framework for them, then you're no longer talking about
_unit_ tests, you're talking about module- or package-level testing
frameworks, and you should be using something more suitable for that,
not unittest.


 
 The problem with D's unit test support is that it doesn't integrate
 well into real world build processes. I usually have debug and release
 configurations, and that's it. No test configuration; not only does
 that over-complicate things, but it also isn't really useful. I want
 my unit testing to be exhaustive; i.e. I want to test my code in debug
 and release builds, because those are the builds people are going to
 be using. Not a test build.

I see. Personally, I just use a more flexible build system where I can specify an argument to indicate whether or not to compile with -unittest. But you may have other reasons why this is not a good thing.
 So, this means that writing unit tests inline is a no-go because that
 would require either always building with unit tests in all
 configurations (madness) or having a test configuration (see above).

I wonder if dmd (or rdmd) should have a mode where it *only* compiles unittest code (i.e., no main() -- the resulting exe just runs unittests and nothing else). But then again, it sounds like you have an extensive testing framework in place, and if you have that already, then might as well use it.
 Given the above, I've resorted to having a "tester" executable which
 links in all libraries in my project and tests every module. This
 means that I have to write my unit tests inside this helper
 executable, making much of the gain in D's unittest blocks go away.
 
 And no, the fact that I link libraries into the helper executable
 doesn't mean that I can just write the unit tests in the libraries in
 the first place. Doing so would require building them twice: Once for
 the normal build and once for the "tester" executable.
 
 (And yes, build times matter when your project gets large enough, even
 in D.)

True. T -- "I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf, Iraqi Minister of Information
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 03:16:57 UTC, Alex Rønne Petersen 
wrote:
 The problem with D's unit test support is that it doesn't 
 integrate well into real world build processes. I usually have 
 debug and release configurations, and that's it. No test 
 configuration; not only does that over-complicate things, but 
 it also isn't really useful. I want my unit testing to be 
 exhaustive; i.e. I want to test my code in debug and release 
 builds, because those are the builds people are going to be 
 using. Not a test build.

 So, this means that writing unit tests inline is a no-go 
 because that would require either always building with unit 
 tests in all configurations (madness) or having a test 
 configuration (see above).

 Given the above, I've resorted to having a "tester" executable 
 which links in all libraries in my project and tests every 
 module. This means that I have to write my unit tests inside 
 this helper executable, making much of the gain in D's unittest 
 blocks go away.

 And no, the fact that I link libraries into the helper 
 executable doesn't mean that I can just write the unit tests in 
 the libraries in the first place. Doing so would require 
 building them twice: Once for the normal build and once for the 
 "tester" executable.

OK, that makes sense. What a test framework could do, although it's kind of ugly, is first copy the unittest() sections into separate test files, compile them and then link with the tested module code. You would keep the advantage of having test code close to source code, and still compile the real code without -unittest switch.
 (And yes, build times matter when your project gets large 
 enough, even in D.)

Just for information, how big is your project (how many files), and how long does a full build take ? I have no idea how fast the compiler really is (is it GDC or DMD you are using ?).
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 15:19:29 UTC, Alex Rønne Petersen 
wrote:
 On 30-04-2012 11:46, SomeDude wrote:

 I don't have a clone of my repo from where I am now, so I can't 
 count, but it usually takes around ~30 seconds with DMD, ~2 
 minutes with GDC.

For how many files/lines of code ?
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 16:14:58 UTC, SomeDude wrote:
 On Monday, 30 April 2012 at 15:19:29 UTC, Alex Rønne Petersen 
 wrote:
 On 30-04-2012 11:46, SomeDude wrote:

 I don't have a clone of my repo from where I am now, so I 
 can't count, but it usually takes around ~30 seconds with DMD, 
 ~2 minutes with GDC.

For how many files/lines of code ?

And on what hardware ? I'd like to have a bit of an idea of how fast the compilers really are.
Apr 30 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 April 2012 17:16, SomeDude <lovelydear mailmetrash.com> wrote:
 On Monday, 30 April 2012 at 16:14:58 UTC, SomeDude wrote:
 On Monday, 30 April 2012 at 15:19:29 UTC, Alex R=F8nne Petersen wrote:
 On 30-04-2012 11:46, SomeDude wrote:

 I don't have a clone of my repo from where I am now, so I can't count,
 but it usually takes around ~30 seconds with DMD, ~2 minutes with GDC.

For how many files/lines of code ?

And on what hardware ? I'd like to have a bit of an idea of how fast the compilers really are.

That sort of speed difference sounds about right. I'm not sure how the DMD backend works, but I assume that there is no more than about 3 passes. A conversion from D Frontend AST to DM Backend AST, possibly a peephole optimiser, then an output to object code. GCC backend has some 50+ passes it processes the generated AST through passed from GDC. Not to mention it only outputs assembly code. So there is some overhead for calling AS to compile to object code (something that DMD just compiles straight to), and double overhead for calling LD to link the resultant binary/library. Regards --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Apr 30 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 April 2012 17:44, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 On 30 April 2012 17:16, SomeDude <lovelydear mailmetrash.com> wrote:
 On Monday, 30 April 2012 at 16:14:58 UTC, SomeDude wrote:
 On Monday, 30 April 2012 at 15:19:29 UTC, Alex R=F8nne Petersen wrote:
 On 30-04-2012 11:46, SomeDude wrote:

 I don't have a clone of my repo from where I am now, so I can't count,
 but it usually takes around ~30 seconds with DMD, ~2 minutes with GDC.

For how many files/lines of code ?

And on what hardware ? I'd like to have a bit of an idea of how fast the compilers really are.

That sort of speed difference sounds about right. =A0I'm not sure how the DMD backend works, but I assume that there is no more than about 3 passes. =A0A conversion from D Frontend AST to DM Backend AST, possibly a peephole optimiser, then an output to object code. GCC backend has some 50+ passes it processes the generated AST through passed from GDC. Not to mention it only outputs assembly code. =A0So there is some overhead for calling AS to compile to object code (something that DMD just compiles straight to), and double overhead for calling LD to link the resultant binary/library.

Having said that, I did produce a report from GDC once with a list of times it takes to compile D2 code (in this instance, libphobos and druntime). http://iainbuclaw.files.wordpress.com/2010/09/d2-time-report2.pdf TOTAL is the total time taken (ie: 0.08 seconds in the first file), and the other elements are a breakdown of what passes took the longest amount of processing time during the entire compilation. If you could get DMD to pull off a similar report, you'd have something nice to compare to. ;-) Regards --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Apr 30 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/30/12, SomeDude <lovelydear mailmetrash.com> wrote:
 I'd like to have a bit of an idea of how
 fast the compilers really are.

Personally my gripe with compilation times is that I get very used to having fast build times where I can go through an edit+compile+run cycle really fast, but after a while build times get slower (especially when templates get in the mix) and this really throws me off. Sometimes I wish I could just interpret D code at runtime just to save on compilation time, because I might just be testing the semantics of code and not necessarily its performance at a time.
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 19:08:54 UTC, Andrej Mitrovic wrote:
 On 4/30/12, SomeDude <lovelydear mailmetrash.com> wrote:
 I'd like to have a bit of an idea of how
 fast the compilers really are.

Personally my gripe with compilation times is that I get very used to having fast build times where I can go through an edit+compile+run cycle really fast, but after a while build times get slower (especially when templates get in the mix) and this really throws me off. Sometimes I wish I could just interpret D code at runtime just to save on compilation time, because I might just be testing the semantics of code and not necessarily its performance at a time.

Yeah, templates is what slows everything down. I'd be very wary of using Boost in C++, for instance, because heavy usage of templates in C++ can slow your development cycle to a crawl in a large project. But in D, the risk of recompilation is limited by the module system, right ?
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 21:11:20 UTC, SomeDude wrote:
 But in D, the risk of recompilation is limited by the module 
 system, right ?

Also, in D, bugs in the CTFE slows everything down, in particular this one: http://d.puremagic.com/issues/show_bug.cgi?id=6498
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 16:54:48 UTC, Iain Buclaw wrote:
 Having said that, I did produce a report from GDC once with a 
 list of
 times it takes to compile D2 code (in this instance, libphobos 
 and
 druntime).

 http://iainbuclaw.files.wordpress.com/2010/09/d2-time-report2.pdf

 TOTAL is the total time taken (ie: 0.08 seconds in the first 
 file),
 and the other elements are a breakdown of what passes took the 
 longest
 amount of processing time during the entire compilation.


 If you could get DMD to pull off a similar report, you'd have
 something nice to compare to. ;-)


 Regards

Thx, that's interesting.
Apr 30 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/30/12, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 Personally my gripe with compilation times is that I get very used to
 having fast build times where I can go through an edit+compile+run
 cycle really fast, but after a while build times get slower

Also since 2.059 error reporting is *completely* broken. I have to wait 5 seconds just to get this error message itself to print to the screen: http://pastebin.com/y93GEPAf 500 lines of errors even though only the first line is an actual error. What in the actual fuck are all those other error messages? The only problem was this line in a main file: CppGen gen; and CppGen was undefined because I've missed an import. And if I remove the only import left (std.range), I get much less garbage but I still get unrelated errors: main.d(80): Error: undefined identifier CppGen D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template std.conv.toImpl does not match any function template declaration D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template std.conv.toImpl cannot deduce template function from argument types !(string)(long) D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template instance toImpl!(string) errors instantiating template loader\gcc.d(167): Error: template instance std.conv.to!(string).to!(long) error instantiating 2.058 error reporting worked fine, I don't know what someone did to screw this up so massively.
May 08 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/8/12, Don Clugston <dac nospam.com> wrote:
 That bug was fixed in git not long after release.

I still get it with this version: http://d.puremagic.com/test-results/test_data.ghtml?dataid=180993 Same errors: http://pastebin.com/8uqgskHd
May 08 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/9/12, Don Clugston <dac nospam.com> wrote:
 OK, looks like it's a different bug. Please put in bugzilla, with status
 of regression.

It turns out it's not a regression: http://d.puremagic.com/issues/show_bug.cgi?id=8082 Something odd about module compilation order which makes unrelated modules error out.
May 11 2012
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/11/12, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 It turns out it's not a regression:
 http://d.puremagic.com/issues/show_bug.cgi?id=8082
 Something odd about module compilation order which makes unrelated
 modules error out.

In my project making sure my main.d file is compiled *last* reduces the error count from ~400 lines to just 2 error lines.
May 11 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 09:53:15 Dmitry Olshansky wrote:
 On 29.04.2012 4:31, Jonathan M Davis wrote:
 For better or worse, the solution for smart pointers in D would be to use
 opDispatch,

*cough* alias this *cough*

That's not necessarily a good idea, depending on how it's used. You want to avoid having the smart pointer implicitly convert to what it holds such that a reference to it leaks. If you're dealing with a pointer to a struct, and alias this aliases to the struct (rather than the pointer), then you're okay. But if you're dealing with a class, you don't have that option. So, alias this ends up leaking a reference to the class, which defeats the purpose of the smart pointer. You have the same problem if alias this aliases to the pointer rather than what's pointed to. But regardless of whether you use alias this or opDispatch, you have the same problem with regards to ->. In C++, . would be used to call the smart pointer's functions, and -> would be used to call functions on the object pointed to. In D, the two aren't distinguished - both use . - so you can't have any functions on the type pointed to which conflict with the smart pointer's functions, or you won't be able to call them (unless another way to call them is provided somehow). So, it's definitely something that C++ does better with as far as that goes. - Jonathan M Davis
Apr 28 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Sunday, 29 April 2012 at 00:40:01 UTC, Era Scarecrow wrote:
 On Saturday, 28 April 2012 at 23:50:22 UTC, foobar wrote:
 On Saturday, 28 April 2012 at 21:02:25 UTC, H. S. Teoh wrote:
 * di files - a library should encapsulate all the info 
 required
 to use it. Java Jars, .Net assemblies and even old school; 
 Pascal
 units all solved this long ago.



 I agree with the general notion here. Whatever the actual 
 implementation details are, the API should be strongly tied to 
 the binary in order to insure consistency and ease of use. I 
 shouldn't need to worry if the header files match the binary 
 library. Regarding the human readable API - that's why we have 
 documentation for.

Mmm well the main reason I see using .di files, is cases when the input library/file/dll doesn't give you much or any information. like... most dll's today. There's also tools to strip that extra debugging and structure information from your output file, so if you distribute a binary only, you still need to include it's .h file or .di file. Cases where this would be far more relevant could be in systems that don't have a lot of room (mini-distros or recovery disks for example). I've seen a recovery disk distro with everything you needed 2 floppies disks. Only reason I don't use floppies anymore is the ones being made are crap and don't keep data where as 14 years ago I could accidentally put mine through the wash and still access it's contents. (Cheap bastards)

floppies, are you for real?! This is only relevant if you travel a decade or so back in time. The current generation dvd/Blu-ray discs and USB sticks aren't good enough for you?
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 06:11:00 UTC, Era Scarecrow wrote:
 My list:
 * I'd start with getting rid of foreach completely. (not just 
 foreach_reverse).


 C++ was criticized for a long time for NOT having foreach in 
 the language. Now they have 
 http://www2.research.att.com/~bs/C++0xFAQ.html#for. Also 
 people were so desperate to gave it that even this 
 http://www.boost.org/doc/libs/1_49_0/doc/html/foreach.html was 
 considered a nice addition to boost (and still part of it).

 Obviously somehow you want to go into the opposite direction. 
 Beats me.

If it simplifies code, makes it easier, and is more consistent, having it is better than not having it. Like walter said in one of the recent videos (going native 2012) regarding having an assembler in a language: 'When you need it, you got to have it'. True most features can be re-written as work arounds, but if you don't have to then why insist on it? Backtracking by removing key features which make the language pleasant may throw us back into the C and C++ days. Yes you can do full memory management yourself, and use pointers and pass it's size to functions. We have fat pointers, so why insist on backtracking? At the worst case if it isn't breaking the language leave it alone. If you have good reasons for it, explain them in detail. At best those of us who know better will laugh and move on.

One of the ideas that I see regularly thrown around is to remove more and more things from the core language and put them in the libraries, because it's possible, and it would make for a thinner languages. Well, these are good reasons to do it, but there are many good reasons NOT to do it. Some general reasons: 1. code is uglier when in the libraries. One must add imports, and template code is uglier and harder to write than plain old code. 2. template code makes bigger size executables 3. error messages are more cryptic 4. we like to think that putting things in the library helps changing things easier, but my opinion is, changing fundamental structures in the standard library may actually break more code than changing them in the core language, because of the heavy interplay between modules, and also because the standard library is probably less well tested (in terms of number of regression tests) than the core language. 5. it makes work much harder for tools and parsers Specific to D: 6. my impression is, from what I've seen in Bugzilla, that Phobos bugs tend to stay around longer, because there is not enough workforce on it These a lot of drawbacks in my opinion. Basically, one of the main reasons the D code is clean, is because the core languages features so many useful things, with a nice, clean syntax. Moving them to the standard library will automatically make the code uglier and the language harder to use.
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 06:10:40 UTC, Nick Sabalausky wrote:
 "SomeDude" <lovelydear mailmetrash.com> wrote in message
 news:sxzgfzztxfvsstwrqdiu forum.dlang.org...
 On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
 On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
 On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:

So you don't agree version() is horribly half assed without AND/OR (how do you generate the same code for two different versions without copying or creating a new version covering both cases then?) and that "version = FOO;" makes no sense?

Sorry, with that, I agree. Nick Sabalausky proposed to remove version entirely. But I agree there could be something like: version(LINUX|OSX){ ... } else { ... }

FWIW, one of the big wins I see in migrating "version" to "static if" is switching from the clumbsy "defined/undefined" model to a model of "true/false, undefined is an error". The current "undefined is not an error" stuff is just so...ActionScript 2.

I don't mind changing the semantics of "version", but replacing the KEYWORD "version" with "static if" will make for code that is harder to read for the eye, harder to parse for the tools, and overall uglier. So I want to keep the keyword, which is a very good addition in my opinion.
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 05:54:10 UTC, Marco Leise wrote:
 Am Sat, 28 Apr 2012 15:39:49 -0400
 schrieb "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com>:

 "q66" <quaker66 gmail.com> wrote in message 
 news:ihqjguujvoukhlqcwkyi forum.dlang.org...
 - Phobos is too fat - it needs to shrink to just a few core 
 modules, others being distributed via some system like CPAN 
 for Perl
 - Properties - they're kinda broken at this point and the 
 value is questionable
 -  trusted  system
 - Exception handling - a lot of runtime, questionable value

That's just craziness!

Madness even! AAs are soon mostly in the library and that's a good trade-off; trusted system needs to be there as long as there is safe; exception handling - some people rely on it heavily. See it as the easy way to error out of a function that doesn't normally return anything and cascade up several calls, while being able to release resources in each. I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly. I can agree on the rest.

I don't want AA to be removed from the core language. That would be a big step backward in my opinion. Core language AAs are entirely adequate for a lot of applications, and they make for so much cleaner and easier to read/write code than template notation.
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 28 April 2012 at 23:51:43 UTC, Jonathan M Davis 
wrote:
 But even just storing it in a local variable to use later
 could destroy the locality enough to defeat LDC's optimization.

Huh? I can't think of a situation where a hash table lookup would entail less indirections than dereferencing a pointer stored in a register (resp. the stack, depending on scheduling). David
Apr 29 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 10:07:38 David Nadlinger wrote:
 On Saturday, 28 April 2012 at 23:51:43 UTC, Jonathan M Davis
 
 wrote:
 But even just storing it in a local variable to use later
 could destroy the locality enough to defeat LDC's optimization.

Huh? I can't think of a situation where a hash table lookup would entail less indirections than dereferencing a pointer stored in a register (resp. the stack, depending on scheduling).

If you have something like if(key in aa) { // lots of code func(aa[key]); } the compiler is not necessarily going to be able to determine that the AA has not been changed such that aa[key] can use the same lookup that key in aa did rather than redoing the lookup. A prime example would be if(key in aa) { foo(aa); func(aa[key]); } The compiler doesn't necessarily know that foo won't remove key from aa, so it can't save the result of key in aa to reuse rather than calling aa[key], whereas the programmer could know that foo doesn't do anything to aa which would make a pointer to the element invalid and can guarantee that only one lookup occurs by doing if(auto value = key in aa) { foo(aa); func(value); } And that's just one case where the compiler can't make such an optimization but the programmer can. It's _far_ better iMHO to have in return a pointer than to rely on the compiler removing extraneous lookups. - Jonathan M Davis
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 01:06:54 UTC, bearophile wrote:
 retro() can't replace foreach_reverse until the front-end 
 demonstrability produces asm code equally efficient.
 Loops _must_ be fully efficient, they are a basic language 
 construct, this is very important. Even foreach() is sometimes 
 not equally efficient as a for() in some cases...

Slightly related: For this: --- import core.stdc.stdio; import std.algorithm; import std.range; void main() { int sum; foreach (i; retro(iota(11))) sum += i; printf("%d\n", sum); } --- LDC produces --- __Dmain: pushq %rax movl $0x00000037,%esi xorb %al,%al leaq _.str24(%rip),%rdi # str24 = "%d\n" callq _printf xorl %esi,%esi movl %eax,0x04(%rsp) movl %esi,%eax popq %rdx ret --- Now that's constant folding… ;) David
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 08:20:59 UTC, Jonathan M Davis wrote:
 The compiler doesn't necessarily know that foo won't remove key 
 from aa, so it
 can't save the result of key in aa to reuse rather than calling 
 aa[key],
 whereas the programmer could know that foo doesn't do anything 
 to aa which
 would make a pointer to the element invalid and can guarantee 
 that only one
 lookup occurs by doing
 […]

Yes, point taken, but what does this have to do with locality? David
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 08:13:53 UTC, Nick Sabalausky wrote:
 There will still be sugar in the compiler so they appear to be 
 builtins.
 When the switch happens, I'm sure it'll be transparent - 
 average users
 probably won't even notice. It's just that "behind the scenes" 
 their
 implementation will move from DMD to Druntime.

Hmmm, sounds nice, but bolting the language with the standard library is very risky (and a rather bad idea imho). Unless there is a very lightweight minimalistic core for Phobos (something which I advocate), you bolt a heavyweight library to your language, and that's not good. I'd rather keep the integrated the AAs, which are fine for most applications, and have templated AAs in the library for heavier use. Even though it may seem redundant, it's just as redundant as having arrays in the core language and std.array. Noone would want to remove arrays from the core language, right ?
Apr 29 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 10:22:44 David Nadlinger wrote:
 On Sunday, 29 April 2012 at 08:20:59 UTC, Jonathan M Davis wrote:
 The compiler doesn't necessarily know that foo won't remove key
 from aa, so it
 can't save the result of key in aa to reuse rather than calling
 aa[key],
 whereas the programmer could know that foo doesn't do anything
 to aa which
 would make a pointer to the element invalid and can guarantee
 that only one
 lookup occurs by doing
 [=E2=80=A6]

Yes, point taken, but what does this have to do with locality?

I think that you're thinking of something completely different about th= e term=20 locality than I meant. I meant locality in terms of how close the aa[ke= y]=20 expression was to the key in aa expression within the function - i.e. h= ow=20 local they were to each other. I may have misused the term though. I do= n't=20 know. - Jonathan M Davis
Apr 29 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 29 April 2012 at 07:00:51 UTC, foobar wrote:
 floppies, are you for real?!
 This is only relevant if you travel a decade or so back in time.
 The current generation dvd/Blu-ray discs and USB sticks aren't 
 good enough for you?

What? I like my floppies... or did when they worked. Depends on what I'm doing; I mean a meg is a lot of space if your primarily doing text and using compression. But I accept it is an old technology and won't be coming back.
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 08:30:15 UTC, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 10:22:44 David Nadlinger wrote:
 Yes, point taken, but what does this have to do with locality?

I think that you're thinking of something completely different about the term locality than I meant. I meant locality in terms of how close the aa[key] expression was to the key in aa expression within the function - i.e. how local they were to each other. I may have misused the term though. I don't know.

Okay, then it was just a misunderstanding, I thought about memory locality. David
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 08:31:57 UTC, Timon Gehr wrote:
 druntime is the library it will be moved into, not Phobos.

Ah, that's ok, then.
Apr 29 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 10:37:10 Timon Gehr wrote:
 Well, what if the programmer "knows" that foo does not change 'aa', but
 it actually does? Then there would possibly be a segmentation fault.
 This implies that the 'in' operator cannot be used in  safe code. (Or
 there would have to be a special case, that allows 'in' if the result is
 directly cast to bool.)

It's exactly as safe as any iterator or range which could be invalidated - both of which can occur in safe code. Any of those could blow up in entertaining ways if you use them after they've been invalidated. Pointers are considered safe. It's pointer arithmetic which isn't. - Jonathan M Davis
Apr 29 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Sunday, 29 April 2012 at 08:58:24 UTC, Timon Gehr wrote:
[...]
 Indeed but I'd go even further by integrating it with ranges 
 so that
 ranges would provide an opApply like method e.g.
 auto r = BinaryTree!T.preOrder(); // returns range
 r.each( (T elem) { ...use elem...}); // each method a-la Ruby

Well, I don't think this is better than built-in foreach (with full break and continue and goto even for user-defined opApply!)

I think we reached a matter of taste here. How often do you use these features anyway in your regular code? I prefer a more functional style with higher order functions (map/reduce/filter/etc..) so for me foreach is about applying something to all elements and doesn't entail usage of break/continue/etc.. I'll use these constructs in a for loop but not a foreach loop.
 * enum - enum should be completely redesigned to only 
 implement
 what it's named after: enumerations.

What is the benefit?

On the one hand the current enum for manifest constants is a hack due to weaknesses of the toolchain

I think that is actually not true. It might have been the original motivation, but it has gone beyond that. Which weaknesses in particular? I don't think that the toolchain can be improved in any way in this regard.

The weakness as far as I know is about link time optimization of constants. But regardless, my ideal implementation of so called "compile-time" features, including compile time constants, would be very different anyway.
 and on the other hand it doesn't provide
 properly encapsulated enums

Those could in theory be added without removing the manifest constant usage.
 such as for instance the Java 5.0 ones or
 the functional kind.

An algebraic data type is not an 'enumeration', so this is a moot point.

I disagree. They are a generalization of the concept. In fact, functional languages such as ML implement c style enums as an algebraic data type.
[...]

 I should be able to use a *very* minimalistic system to write 
 completely
 _regular_ D code and run it at different times.

Examples in concrete syntax? How would you replace eg. string mixin functionality?
 This is a simple matter
 of separation of concerns: what we want to execute (what code) 
 is
 separate to the concern of when we want to execute it.

It is not. For example, code that is only executed during CTFE does never have to behave gracefully if the input is ill-formed.

I disagree - you should make sure the input is valid or all sorts of bad things could potentially happen such as a compiler can get stuck in an infinite loop. If you only use a batch mode compiler you can simply kill the process which btw applies just the same to your user program. However, if you use an integrated compiler in your IDE that could cause me to lose part of my work if the IDE crashes.
Apr 29 2012
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was which features in D are redundant and/or 
 do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble and creal types.

 What's your list?

garbage collector *duck and run* The point I'm trying to make is... normally I would use around 4-5 different languages depending on _what_ problem I'm currently solving... occasionally even languages I'm not particularly proficient with, just because a language might have an edge in a certain domain... however 'D' basically is good enough at "everything"... with some few exceptions. So what one person considers redundant, is integral to someone else with a different background... no, D doesn't have too many features.
Apr 29 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Sunday, 29 April 2012 at 11:23:17 UTC, Timon Gehr wrote:
 On 04/29/2012 11:31 AM, foobar wrote:
 On Sunday, 29 April 2012 at 08:58:24 UTC, Timon Gehr wrote:
 [...]
 Indeed but I'd go even further by integrating it with ranges 
 so that
 ranges would provide an opApply like method e.g.
 auto r = BinaryTree!T.preOrder(); // returns range
 r.each( (T elem) { ...use elem...}); // each method a-la Ruby

Well, I don't think this is better than built-in foreach (with full break and continue and goto even for user-defined opApply!)

I think we reached a matter of taste here.

Certainly, and this applies to the other issues as well.
 How often do you use these features anyway in your regular 
 code?

Not too often, but it is awesome that it actually works. ;)
 I prefer a more functional style
 with higher order functions (map/reduce/filter/etc..) so for 
 me foreach
 is about applying something to all elements and doesn't entail 
 usage of
 break/continue/etc..

Some algorithms are better expressed in functional terms, some algorithms are better expressed in imperative terms. I think a combination of the two usually is the best choice.

I agree and indeed I haven't argued to remove break/continue from the language. Imperative style loops are already expressible with for/while/etc where break/continue work as advertizes. IMO a foreach loop is a higher level concept more suitable for functional style loops. In any case, break/continue is implemented via opApply's return values and as such doesn't require anything special from the compiler to implement a library based foreach.
 I'll use these constructs in a for loop but not a foreach loop.

break can be used as an optimisation to stop execution of a loop that performs a 'reduce' if the result cannot change after a certain point. I use continue mostly for 'filter'-ing out elements from consideration.

Well, I'll use a filter to filter out elements.... :)
 Usually there is not a huge difference between imperative style 
 and functional style loops.

 * enum - enum should be completely redesigned to only 
 implement
 what it's named after: enumerations.

What is the benefit?

On the one hand the current enum for manifest constants is a hack due to weaknesses of the toolchain

I think that is actually not true. It might have been the original motivation, but it has gone beyond that. Which weaknesses in particular? I don't think that the toolchain can be improved in any way in this regard.

The weakness as far as I know is about link time optimization of constants. But regardless, my ideal implementation of so called "compile-time" features, including compile time constants, would be very different anyway.

Well, you never elaborate on these things. BTW, what is your stance on template haskell?

I discussed this many times in the past... I don't really know haskell. But I do like ML.
 and on the other hand it doesn't provide
 properly encapsulated enums

Those could in theory be added without removing the manifest constant usage.
 such as for instance the Java 5.0 ones or
 the functional kind.

An algebraic data type is not an 'enumeration', so this is a moot point.

I disagree. They are a generalization of the concept. In fact, functional languages such as ML implement c style enums as an algebraic data type.

The current way enums can be used as manifest constants is a generalization as well. The generalization takes place on the static semantics level instead of on the conceptual level though.

A language is the interface between a human programmer and a computer and should IMO provide clear conceptual level abstractions for the benefit of the human. I realize that using enum for manifest constants makes sense on the implementation level but I feel the compiler should work for me and not the other way around.
 [...]

 I should be able to use a *very* minimalistic system to 
 write completely
 _regular_ D code and run it at different times.

Examples in concrete syntax? How would you replace eg. string mixin functionality?


?

macro testMacro() { std.writeln("Hello world!"); <| std.writeln("Hello world!"); |> } macro is a syntactic sugar on top of a regular function. You can call it just like you call a regular function. The first line is executed regularly and the second one is mixed-in [returned token stream from the macro] since the macro is evaluated by the compiler, the first line would generate compile-time output. the second line would be part of the generated code and would be thus executed during run-time of my code. Regarding syntax, the main difference is that it's a token stream and not text but otherwise pretty much the same as current CTFE. The important difference here is the execution model which is different from CTFE.
 This is a simple matter
 of separation of concerns: what we want to execute (what 
 code) is
 separate to the concern of when we want to execute it.

It is not. For example, code that is only executed during CTFE does never have to behave gracefully if the input is ill-formed.

I disagree - you should make sure the input is valid or all sorts of bad things could potentially happen such as a compiler can get stuck in an infinite loop.

It could fail in a number of other ways. I don't think that this example can be used to invalidate the statement.
 If you only use a batch mode compiler you can simply kill
 the process which btw applies just the same to your user 
 program.

Maybe the user program should not be killed. See your IDE example.
 However, if you use an integrated compiler in your IDE that 
 could cause
 me to lose part of my work if the IDE crashes.

Why would the IDE crash?

My example illustrates that the same considerations should be given to "compile-time" code as well as to the client application and it all depends on what you're trying to achieve.
Apr 29 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 What's your list?

My personal list of features I could easily live without – some of these might be controversial, but yes, I have written non-trivial amounts of code in both D1 and D2: - Anonymous nested classes: They might be useful in Java, particularly in older incarnations, but not so much in D – never used them. - Comma operator: Kill it with extreme prejudice, it is an anti-feature (allow it in for loop expressions if you really want to, but I think there are better solutions). - Typesafe variadics: They look nice on paper, but I haven't used them once. Often, you either explicitly need C-style variadics, or you want to accept e.g. multiple ranges of the same element type, where you need template variadics anyway. - Unsigned right shift, but I can see how it can be useful (simply underused?). - HexString, DelimitedString, r""-WysiwigString, TokenString: I didn't ever use the former two (for including binary data in the program, ImportExpression is imho much easier than generating a source file containing a HexString). As for r"", every time I actually need WysiwigString, I use backticks, because such strings often contain quotes anyway. Regarding TokenString(i.e. q{}) – it is certainly a very nice idea, especially regarding syntax highlighting, and I occasionally use them for CTFE code generation. But without any kind of support for string interpolation, I typically find myself using normal strings for everything except small self-contained portions of code (where mixin templates would probably be cleaner). The problem is that can't just »interrupt« q{}s strings to do something like »q{…} ~ identifierName ~ q{…}«, because there will most likely be unmatched braces – but this is needed in assembling mixin strings all the time… - Concatenation of adjacent strings: Also an anti-feature, imho. - Floating point comparison operators like !<>= (yes, that _is_ valid D code): I must admit that I seldom write code relying on the finer details of IEEE-754 semantics, but can't they just be »lowered« to a combination of the more common ones? - »Short« floating point literals like .4 instead of 0.4 and 4. instead of 4.0 – the saved characters are not worth the syntax special cases, especially w.r.t. UFCS. - new/delete issues have been discussed many times - Built-in arrays and AAs: They are convenient to use, but as far as I can see the single biggest GC dependency in the language. Why not lower array and AA literals to expression tuples (or whatever) to make the convenient syntax usable with custom (possibly non-GC safe) containers as well? A GC'd default implementation could then be provided in druntime, just like today's arrays and AAs. - shared: TLS by default is great, but only __gshared is really usable right now. IMHO, shared had better been reserved for a comprehensive take on the subject, rather than the half-baked implementation we have right now. David
Apr 29 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 02:26 PM, David Nadlinger wrote:
 TokenString: [...]Regarding TokenString(i.e. q{}) – it is certainly a very
 nice idea, especially regarding syntax highlighting, and I occasionally
 use them for CTFE code generation. But without any kind of support for
 string interpolation, I typically find myself using normal strings for
 everything except small self-contained portions of code (where mixin
 templates would probably be cleaner). The problem is that can't just
 »interrupt« q{}s strings to do something like »q{…} ~ identifierName ~
 q{…}«, because there will most likely be unmatched braces – but this is
 needed in assembling mixin strings all the time…

Lack of string interpolation is not a reason to kill the token string, because CTFE lets you provide the interpolation manually. I use token strings often in this fashion for code generation.
 - Floating point comparison operators like !<>= (yes, that _is_ valid D
 code): I must admit that I seldom write code relying on the finer
 details of IEEE-754 semantics, but can't they just be »lowered« to a
 combination of the more common ones?

I kinda like those ;D.
Apr 29 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 14:26, David Nadlinger wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 What's your list?

My personal list of features I could easily live without – some of these might be controversial, but yes, I have written non-trivial amounts of code in both D1 and D2: - Anonymous nested classes: They might be useful in Java, particularly in older incarnations, but not so much in D – never used them.

I use them. They can be useful when you're writing more object-oriented code than functional style code.
 - Comma operator: Kill it with extreme prejudice, it is an anti-feature
 (allow it in for loop expressions if you really want to, but I think
 there are better solutions).

+9001.
 - Typesafe variadics: They look nice on paper, but I haven't used them
 once. Often, you either explicitly need C-style variadics, or you want
 to accept e.g. multiple ranges of the same element type, where you need
 template variadics anyway.

 - Unsigned right shift, but I can see how it can be useful (simply
 underused?).

It's clear that arithmetic right shift is what the programmer usually wants, and yet, we use >> to denote what they don't want. It's completely counter-intuitive. So, +1.
 - HexString, DelimitedString, r""-WysiwigString, TokenString: I didn't
 ever use the former two (for including binary data in the program,
 ImportExpression is imho much easier than generating a source file
 containing a HexString). As for r"", every time I actually need
 WysiwigString, I use backticks, because such strings often contain
 quotes anyway. Regarding TokenString(i.e. q{}) – it is certainly a very
 nice idea, especially regarding syntax highlighting, and I occasionally
 use them for CTFE code generation. But without any kind of support for
 string interpolation, I typically find myself using normal strings for
 everything except small self-contained portions of code (where mixin
 templates would probably be cleaner). The problem is that can't just
 »interrupt« q{}s strings to do something like »q{…} ~ identifierName ~
 q{…}«, because there will most likely be unmatched braces – but this is
 needed in assembling mixin strings all the time…

 - Concatenation of adjacent strings: Also an anti-feature, imho.

+1.
 - Floating point comparison operators like !<>= (yes, that _is_ valid D
 code): I must admit that I seldom write code relying on the finer
 details of IEEE-754 semantics, but can't they just be »lowered« to a
 combination of the more common ones?

Why not just make them intrinsics? What are they doing in the language? You're rarely, if ever, going to actually be using these operators because NaN is, well, an invalid state, like null. +1.
 - »Short« floating point literals like .4 instead of 0.4 and 4. instead
 of 4.0 – the saved characters are not worth the syntax special cases,
 especially w.r.t. UFCS.

+1. I find it to be poor style to not include the ".0" in FP literals.
 - new/delete issues have been discussed many times

 - Built-in arrays and AAs: They are convenient to use, but as far as I
 can see the single biggest GC dependency in the language. Why not lower
 array and AA literals to expression tuples (or whatever) to make the
 convenient syntax usable with custom (possibly non-GC safe) containers
 as well? A GC'd default implementation could then be provided in
 druntime, just like today's arrays and AAs.

Sounds reasonable.
 - shared: TLS by default is great, but only __gshared is really usable
 right now. IMHO, shared had better been reserved for a comprehensive
 take on the subject, rather than the half-baked implementation we have
 right now.

 David

It's clear that shared is biased towards heavily templatized code. It's not useful in non-templatized code because such code can't accept both shared and non-shared values. shared looks neat in theory, but is a fallacy in practice. -- - Alex
Apr 29 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 10:59 PM, Alex Rønne Petersen wrote:
 On 29-04-2012 14:26, David Nadlinger wrote:
 - Unsigned right shift, but I can see how it can be useful (simply
 underused?).

It's clear that arithmetic right shift is what the programmer usually wants, and yet, we use >> to denote what they don't want. It's completely counter-intuitive. So, +1.

'>>' is arithmetic right shift.
 - shared: TLS by default is great, but only __gshared is really usable
 right now. IMHO, shared had better been reserved for a comprehensive
 take on the subject, rather than the half-baked implementation we have
 right now.

 David

It's clear that shared is biased towards heavily templatized code. It's not useful in non-templatized code because such code can't accept both shared and non-shared values.

Just cast it away if you do eg. locking. There is nothing wrong with it. Code that operates on both (actually) shared and unshared data should be uncommon anyway.
 shared looks neat in theory, but is a fallacy in practice.

unshared is what is important. There is no unshared if there is no shared.
Apr 29 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 00:08, Timon Gehr wrote:
 On 04/29/2012 10:59 PM, Alex Rønne Petersen wrote:
 On 29-04-2012 14:26, David Nadlinger wrote:
 - Unsigned right shift, but I can see how it can be useful (simply
 underused?).

It's clear that arithmetic right shift is what the programmer usually wants, and yet, we use >> to denote what they don't want. It's completely counter-intuitive. So, +1.

'>>' is arithmetic right shift.

Sorry, I managed to get myself confused here. What I meant to say was that I think >> should do an arithmetic shift if the operands are signed; unsigned shift otherwise.
 - shared: TLS by default is great, but only __gshared is really usable
 right now. IMHO, shared had better been reserved for a comprehensive
 take on the subject, rather than the half-baked implementation we have
 right now.

 David

It's clear that shared is biased towards heavily templatized code. It's not useful in non-templatized code because such code can't accept both shared and non-shared values.

Just cast it away if you do eg. locking. There is nothing wrong with it. Code that operates on both (actually) shared and unshared data should be uncommon anyway.

The problem is that shared is supposed to insert memory barriers (I know it doesn't, but that's the goal/idea).
 shared looks neat in theory, but is a fallacy in practice.

unshared is what is important. There is no unshared if there is no shared.

I think this statement went over my head... -- - Alex
Apr 29 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 08:37, jerro wrote:
 Sorry, I managed to get myself confused here. What I meant to say was
 that I think >> should do an arithmetic shift if the operands are
 signed; unsigned shift otherwise.

It does arithmetic shift if the left operand is signed, unsigned shift otherwise. This code: void main() { int a = 0xffffffff; uint b = a; writefln("%x", a >> 1); writefln("%x", b >> 1); } prints ffffffff 7fffffff

The documentation disagrees: http://dlang.org/expression.html#ShiftExpression It claims that it always does arithmetic shift and >>> always does unsigned shift. -- - Alex
Apr 30 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 05:21 PM, Alex Rønne Petersen wrote:
 On 30-04-2012 08:37, jerro wrote:
 Sorry, I managed to get myself confused here. What I meant to say was
 that I think >> should do an arithmetic shift if the operands are
 signed; unsigned shift otherwise.

It does arithmetic shift if the left operand is signed, unsigned shift otherwise. This code: void main() { int a = 0xffffffff; uint b = a; writefln("%x", a >> 1); writefln("%x", b >> 1); } prints ffffffff 7fffffff

The documentation disagrees: http://dlang.org/expression.html#ShiftExpression It claims that it always does arithmetic shift and >>> always does unsigned shift.

http://d.puremagic.com/issues/show_bug.cgi?id=8007
Apr 30 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 20:17, Timon Gehr wrote:
 On 04/30/2012 05:21 PM, Alex Rønne Petersen wrote:
 On 30-04-2012 08:37, jerro wrote:
 Sorry, I managed to get myself confused here. What I meant to say was
 that I think >> should do an arithmetic shift if the operands are
 signed; unsigned shift otherwise.

It does arithmetic shift if the left operand is signed, unsigned shift otherwise. This code: void main() { int a = 0xffffffff; uint b = a; writefln("%x", a >> 1); writefln("%x", b >> 1); } prints ffffffff 7fffffff

The documentation disagrees: http://dlang.org/expression.html#ShiftExpression It claims that it always does arithmetic shift and >>> always does unsigned shift.

http://d.puremagic.com/issues/show_bug.cgi?id=8007

Thanks; these kinds of documentation bugs can cause really nasty misunderstandings. -- - Alex
Apr 30 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 08:30 PM, Alex Rønne Petersen wrote:
 On 30-04-2012 20:17, Timon Gehr wrote:
 On 04/30/2012 05:21 PM, Alex Rønne Petersen wrote:
 On 30-04-2012 08:37, jerro wrote:
 Sorry, I managed to get myself confused here. What I meant to say was
 that I think >> should do an arithmetic shift if the operands are
 signed; unsigned shift otherwise.

It does arithmetic shift if the left operand is signed, unsigned shift otherwise. This code: void main() { int a = 0xffffffff; uint b = a; writefln("%x", a >> 1); writefln("%x", b >> 1); } prints ffffffff 7fffffff

The documentation disagrees: http://dlang.org/expression.html#ShiftExpression It claims that it always does arithmetic shift and >>> always does unsigned shift.

http://d.puremagic.com/issues/show_bug.cgi?id=8007

Thanks; these kinds of documentation bugs can cause really nasty misunderstandings.

I don't trust the documentation. In my experience, it is usually best to rely on common sense to get a grasp for how a feature is supposed to behave (that works surprisingly well!) and occasionally file bug reports if either the documentation or DMD is strange in a certain aspect. (I'll probably file a bunch of implicit-conversion related bugs tomorrow.)
Apr 30 2012
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 21:19, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 12:26:13 UTC, David Nadlinger wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 What's your list?

My personal list of features I could easily live without – some of these might be controversial, but yes, I have written non-trivial amounts of code in both D1 and D2:

What I forgot to mention: - VersionCondition: Just provide a mechanism to map command line flags to constants, probably in a magic »version« namespace, and use static if (e.g. »version (Foo)« -> »static if (version.Foo)«, »version (unittest)« -> »static if (unittest)«).

Something like that seems reasonable. At any rate, version in its current state is not very useful in practice.
 - DebugCondition: Hardly used in practice, at least not in ways that
 couldn't easily be replaced with a static if (resp. version). It is a
 frequent source of confusion for newcomers that -debug is orthogonal to
 -O/-release, and I'm not too fond of the purity »escape hatch« built in
 (why not just use casts in those rare cases?).

+1. And debug being a keyword is more annoying than you'd think.
 David

-- - Alex
Apr 29 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 30.04.2012 9:33, H. S. Teoh wrote:
 On Mon, Apr 30, 2012 at 07:07:53AM +0200, David Nadlinger wrote:
 On Monday, 30 April 2012 at 03:16:09 UTC, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 02:26:12PM +0200, David Nadlinger wrote:
 […]
 - Built-in arrays and AAs: They are convenient to use, but as
 far as I can see the single biggest GC dependency in the language.
 Why not lower array and AA literals to expression tuples (or
 whatever) to make the convenient syntax usable with custom (possibly
 non-GC safe) containers as well? A GC'd default implementation could
 then be provided in druntime, just like today's arrays and AAs.

AA's are moving into druntime. Yours truly is supposed to make that happen eventually, but lately time hasn't been on my side. :-/

This moves the _implementation_ to druntime, but there is still realistically no way to use AA literals with my own non-GC'd version of hash maps without shipping a custom druntime (and thus modifying the semantics of an existing language construct). What I'm talking about would let you do things like MyVector!int stuff = [1, 2, 3, 4, 5]; without needing a (temporary) GC'd allocation, and thus please the GC-hater crowd because they can still have all the syntax candy with their own containers, even if they can't resp. don't want to use the default GC'd constructs.

I think you're talking about two orthogonal issues here. One is language-level support for arrays and AA's, which IMO are necessary and are even a plus (built-in AA's are one of the big reasons I chose D). The other is language-level support for literal syntax in user-defined types. I think the latter area has lots of room for improvement. From a theoretical standpoint, syntax like [1,2,3,4,5] really should not be prematurely tied to a specific type: at the most fundamental level, it's just specifying a list of things. How the abstract concept of a list of things should be implemented need not be constrained to concrete built-in types; I'd argue that the language should permit the realization of the concept in a user-defined type as well (i.e., the literal interpreted by a user type). Just off the top of my head, this might be achievable by introducing a fromList method in user-defined types that takes a compile-time parameter containing some representation of the list, say as a builtin array. This method then does whatever is needed to create an instance of the type accordingly. (Since the parameter is compile-time, this essentially just generates code to create the custom container directly.) The same thing can be done for custom floating-point literals, say. A fromFloat() method takes a compile-time string containing the literal, and creates an instance of the custom type. (A string is used here so that you can implement types that far exceed the maximum precision of any builtin type.) Ditto for AA literals: a fromAA() method takes a compile-time list of key/value pairs and does whatever it needs to do to create the appropriate runtime AA. In fact, such a construct would alleviate much of the need for compiler hacks to support AA's (both old and the prospective new replacement). There will be no unnecessary overhead of allocating runtime arrays, copying, etc.; the fromAA() method at compile-time generates whatever code is necessary to create the literal into the target object directly. This is a language enhancement issue, though, not really an issue about builtin AA's or arrays being "unnecessary features".

*cough* initializer lists *cough* Seriously let AA liters be an sorted initializer list (conceptual compile-time array) of pairs, and normal array literal just plain initializer list of common type. This also nails nicely strange use case of AA literal to build array (just the same sorted table of pairs!). The AA then is just initialized with sorted array at run-time. (as it does anyway) -- Dmitry Olshansky
Apr 30 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 30.04.2012 23:14, H. S. Teoh wrote:
 On Mon, Apr 30, 2012 at 09:06:06PM +0200, Andrej Mitrovic wrote:
 On 4/30/12, H. S. Teoh<hsteoh quickfur.ath.cx>  wrote:
 Then
 you can write:

 	uint[] a = [
 		2: 100,
 		10: 200
 	]

 and it will be equivalent to:

 	uint[] a = [0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 200];

But you can already use this syntax right now?

Yes I know you can, it was more of using this syntax for user-defined types without allocating a temporary array.

Yes I tried to point out that this also makes this code straight forward. AND allows other AA-like enitites to benefit from it. Most importantly it doesn't break a thing. Just generalizes. -- Dmitry Olshansky
Apr 30 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/29/2012 5:26 AM, David Nadlinger wrote:
 - Anonymous nested classes: They might be useful in Java, particularly in older
 incarnations, but not so much in D – never used them.

I don't like them, either, but they were put in at the recommendation of people who were porting large piles of Java code to D. It made semi-mechanical translation much more feasible. Using them for any other purpose is likely a bad idea, as the only reason they exist in Java is as a kludge to work around limitations in Java.
Apr 30 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 16:28:23 Dmitry Olshansky wrote:
 On 29.04.2012 10:42, Jonathan M Davis wrote:
 But regardless of whether you use alias this or opDispatch, you have the
 same problem with regards to ->. In C++, . would be used to call the
 smart pointer's functions, and ->  would be used to call functions on the
 object pointed to. In D, the two aren't distinguished - both use . - so
 you can't have any functions on the type pointed to which conflict with
 the smart pointer's functions, or you won't be able to call them (unless
 another way to call them is provided somehow). So, it's definitely
 something that C++ does better with as far as that goes.

So you just need not to have any _member_ functions on smart pointer? Just use free functions that take SmartPointer!T. UFCS may also lend a hand if T and SmartPointer do not have ambiguous funcs.

That could work (though they'd obviously have to be in the same module as the smart pointer - not exactly an onerous requirement - in order to be able to access its private members). - Jonathan M Davis
Apr 29 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-28 20:47, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

* Some of the built-in properties could probably be move to a library solution, specially now when we have UFCS. * The with-statement isn't particular useful. Although I've started to use it in one of my projects just so I don't have to use fully qualified enum names. * D embedded in HTML (don't know if this is still supported) * Multiple syntax for wysiwyg strings. I think the r"" syntax can be remove. * Do-while loops, how useful are those actually? Then I think some features could be replaced with library solutions if D got some other features. For example: * foreach(_reverse) * synchronized These could probably be removed in favor of library solutions. void foreach (T)(T[] arr, void delegate (ref T) dg) { for (size_t i = 0; i < arr.length; i++) dg(arr[i]); } foreach ([1, 2, 3, 4], (i) { writeln(i); }); The above already works today. If we can a bit syntax sugar for delegates and inlinable delegates we could have this: foreach ([1, 2, 3, 4] ; i) { writeln(i); } The above syntax would be very useful in other cases as well. The same could be done for "synchronized" as well. Might even be possible to remove the for-statement and just have "while" left. I we want get even more wild and crazy I think Scala's solution for operator overloading looks really good. But that would require several other features to work. Like: * Everything is an object (might not be needed with UFCS) * Everything is a method call on an object * Infix notation for calling any method taking one argument * Basically any symbol is allowed in method names That is: 1 + 2 foo bar foo_bar Would be translated to: 1.+(2) foo.bar(foo_bar) That is a very general way to handle operators and let the user create new operators, not just overloading existing ones. -- /Jacob Carlborg
Apr 29 2012
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29.04.2012 18:40, Jacob Carlborg wrote:

 1 + 2
 foo bar foo_bar

 Would be translated to:

 1.+(2)
 foo.bar(foo_bar)

 That is a very general way to handle operators and let the user create
 new operators, not just overloading existing ones.

warning(1): Smalltalk detected! [use -foop-only to ignore] Operator precedence would get real tricky (or stupid just like in Smalltalk). -- Dmitry Olshansky
Apr 29 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
 foreach ([1, 2, 3, 4], (i)  { writeln(i); });

 The above already works today. If we can a bit syntax sugar for 
 delegates and inlinable delegates we could have this:

 foreach ([1, 2, 3, 4] ; i) {
     writeln(i);
 }

We'd still need a solution for continue and break, though. David
Apr 29 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-29 17:07, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
 foreach ([1, 2, 3, 4], (i) { writeln(i); });

 The above already works today. If we can a bit syntax sugar for
 delegates and inlinable delegates we could have this:

 foreach ([1, 2, 3, 4] ; i) {
 writeln(i);
 }

We'd still need a solution for continue and break, though. David

This has already been solved when using opApply, although quite an ugly solution. -- /Jacob Carlborg
Apr 29 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-29 19:03, David Nadlinger wrote:

 Yes, but that requires the compiler to generate the return value »glue«
 code for continue/break inside an opApply foreach. If foreach is a
 library function and you pass an ordinary delegate, you have a problem
 in the current language since you can't know that a »return« statement
 inside that delegate really should return from the outer function.

 David

Yeah, that would need to be solved. In Ruby it works like this: [1, 2, 3, 4].each do |i| if i == 2 return end end Results in: LocalJumpError: unexpected return If you instead wrap it in method you can return from the each-block. So in Ruby it behaves just like having a "return" in a plain for-loop and not in a delegate. It would basically force a return in the "each" method. -- /Jacob Carlborg
Apr 29 2012
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 01:54, Era Scarecrow wrote:
 On Sunday, 29 April 2012 at 15:07:26 UTC, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
 foreach ([1, 2, 3, 4], (i) { writeln(i); });

 The above already works today. If we can a bit syntax sugar for
 delegates and inlinable delegates we could have this:

 foreach ([1, 2, 3, 4] ; i) {
 writeln(i);
 }

We'd still need a solution for continue and break, though.

A thought coming to mind regarding this, is a special exception. If the compiler recognizes it's part of a foreach (or other loop) then continue gets converted to return, and and break throws an exception (caught by the foreach of course) But that involves more compiler magic.

And forced EH which is unacceptable in e.g. a kernel. -- - Alex
Apr 29 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 30/04/2012 06:20, H. S. Teoh a écrit :
 On Mon, Apr 30, 2012 at 01:57:58AM +0200, Alex Rřnne Petersen wrote:
 On 30-04-2012 01:54, Era Scarecrow wrote:
 On Sunday, 29 April 2012 at 15:07:26 UTC, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:



 We'd still need a solution for continue and break, though.

A thought coming to mind regarding this, is a special exception. If the compiler recognizes it's part of a foreach (or other loop) then continue gets converted to return, and and break throws an exception (caught by the foreach of course) But that involves more compiler magic.

And forced EH which is unacceptable in e.g. a kernel.

Here's a wild idea: introduce the concept of the multi-return function (or, in this case, delegate). Unlike normal functions which returns to a single point when they end, usually by pushing the return address onto the runtime stack, a multi-return function is called by pushing _multiple_ return addresses onto the runtime stack. The function body decides which return address to use (it can only use one of them). Implementing break/continue then can be done like this: the loop body delegate will be a multi-return delegate, i.e., a delegate whose caller will provide multiple return addresses: one for each possible break/continue point. For example: outerLoop: foreach (a; containerA) { innerLoop: foreach (b; containerB) { if (condition1()) continue outerLoop; if (condition2()) break /* innerLoop */; if (condition3()) break outerLoop; } if (condition4()) break /* outerLoop */; } When containerA.opApply is called, it calls the outer loop body with two return addresses: the first is the usual return address from a function call, the second is the cleanup code at the end of opApply that performs any necessary cleanups and then returns. I.e., it simulates break. So when condition4 triggers, the outerLoop delegate returns to the second address. Now the outerLoop delegate itself calls containerB.opApply with a list of outer loop return addresses, i.e., (1) return to containerA.opApply's caller, that is, break outerLoop, (2) return to outerLoop delegate's cleanup code, i.e. continue OuterLoop. Then containerB.opApply prepends two more return addresses to this list, the usual return address to containerB.opApply, and its corresponding break return (prepend because the last return addressed pushed must correspond with the immediate containing scope of the called delegate, but if the delegate knows about outer scopes then it can return to those). Now the innerLoop delegate has four return addresses: return to containerB.opApply normally (continue innerLoop), return to containerB.opApply's cleanup code (break innerLoop), return to containerA.opApply normally (continue outerLoop), and return to containerA.opApply's cleanup code (break outerLoop). So break/continue works for all cases. (Of course, containerB.opApply doesn't actually just prepend return addresses to what the outerLoop delegate passes in, since when the innerLoop delegate wants to break outerLoop, it needs to cleanup the stack frames of the intervening call to containerB.opApply too. So containerB.opApply needs to insert its own cleanup code into the return address chain.) This is, at least, the *conceptual* aspect of things. In the actual implementation, the compiler may use the current scheme (return an int to indicate which return is desired) instead of doing what amounts to reinventing stack unwinding, but the important point is, this should be transparent to user code. As far as the user is concerned, they just call the delegate normally, no need to check return codes, etc., with the understanding that the said delegates have multiple return addresses. The compiler inserts the necessary scaffolding, checking for int returns, etc., to actually implement the concept.

This make sense. This seems to me like the way to go.
Apr 30 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 16:10:40 UTC, Jacob Carlborg wrote:
 On 2012-04-29 17:07, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
 foreach ([1, 2, 3, 4] ; i) {
 writeln(i);
 }

We'd still need a solution for continue and break, though. David

This has already been solved when using opApply, although quite an ugly solution.

Yes, but that requires the compiler to generate the return value »glue« code for continue/break inside an opApply foreach. If foreach is a library function and you pass an ordinary delegate, you have a problem in the current language since you can't know that a »return« statement inside that delegate really should return from the outer function. David
Apr 29 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-04-2012 16:40, Jacob Carlborg wrote:
 On 2012-04-28 20:47, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

* Some of the built-in properties could probably be move to a library solution, specially now when we have UFCS.

+1.
 * The with-statement isn't particular useful. Although I've started to
 use it in one of my projects just so I don't have to use fully qualified
 enum names.

It is very useful in some cases where you operate a lot on the same object.
 * D embedded in HTML (don't know if this is still supported)

Madness... I think it's deprecated now.
 * Multiple syntax for wysiwyg strings. I think the r"" syntax can be
 remove.

 * Do-while loops, how useful are those actually?

I use them occasionally, but it's certainly true that they are rarely useful.
 Then I think some features could be replaced with library solutions if D
 got some other features. For example:

 * foreach(_reverse)
 * synchronized

 These could probably be removed in favor of library solutions.

 void foreach (T)(T[] arr, void delegate (ref T) dg)
 {
 for (size_t i = 0; i < arr.length; i++)
 dg(arr[i]);
 }

 foreach ([1, 2, 3, 4], (i) { writeln(i); });

 The above already works today. If we can a bit syntax sugar for
 delegates and inlinable delegates we could have this:

 foreach ([1, 2, 3, 4] ; i) {
 writeln(i);
 }

 The above syntax would be very useful in other cases as well.

 The same could be done for "synchronized" as well. Might even be
 possible to remove the for-statement and just have "while" left.

 I we want get even more wild and crazy I think Scala's solution for
 operator overloading looks really good. But that would require several
 other features to work. Like:

 * Everything is an object (might not be needed with UFCS)
 * Everything is a method call on an object
 * Infix notation for calling any method taking one argument
 * Basically any symbol is allowed in method names

 That is:

 1 + 2
 foo bar foo_bar

 Would be translated to:

 1.+(2)
 foo.bar(foo_bar)

 That is a very general way to handle operators and let the user create
 new operators, not just overloading existing ones.

-- - Alex
Apr 29 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Sunday, 29 April 2012 at 15:07:26 UTC, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
 foreach ([1, 2, 3, 4], (i)  { writeln(i); });

 The above already works today. If we can a bit syntax sugar 
 for delegates and inlinable delegates we could have this:

 foreach ([1, 2, 3, 4] ; i) {
    writeln(i);
 }

We'd still need a solution for continue and break, though.

A thought coming to mind regarding this, is a special exception. If the compiler recognizes it's part of a foreach (or other loop) then continue gets converted to return, and and break throws an exception (caught by the foreach of course) But that involves more compiler magic.
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 01:57:58AM +0200, Alex Rřnne Petersen wrote:
 On 30-04-2012 01:54, Era Scarecrow wrote:
On Sunday, 29 April 2012 at 15:07:26 UTC, David Nadlinger wrote:
On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:



We'd still need a solution for continue and break, though.

A thought coming to mind regarding this, is a special exception. If the compiler recognizes it's part of a foreach (or other loop) then continue gets converted to return, and and break throws an exception (caught by the foreach of course) But that involves more compiler magic.

And forced EH which is unacceptable in e.g. a kernel.

Here's a wild idea: introduce the concept of the multi-return function (or, in this case, delegate). Unlike normal functions which returns to a single point when they end, usually by pushing the return address onto the runtime stack, a multi-return function is called by pushing _multiple_ return addresses onto the runtime stack. The function body decides which return address to use (it can only use one of them). Implementing break/continue then can be done like this: the loop body delegate will be a multi-return delegate, i.e., a delegate whose caller will provide multiple return addresses: one for each possible break/continue point. For example: outerLoop: foreach (a; containerA) { innerLoop: foreach (b; containerB) { if (condition1()) continue outerLoop; if (condition2()) break /* innerLoop */; if (condition3()) break outerLoop; } if (condition4()) break /* outerLoop */; } When containerA.opApply is called, it calls the outer loop body with two return addresses: the first is the usual return address from a function call, the second is the cleanup code at the end of opApply that performs any necessary cleanups and then returns. I.e., it simulates break. So when condition4 triggers, the outerLoop delegate returns to the second address. Now the outerLoop delegate itself calls containerB.opApply with a list of outer loop return addresses, i.e., (1) return to containerA.opApply's caller, that is, break outerLoop, (2) return to outerLoop delegate's cleanup code, i.e. continue OuterLoop. Then containerB.opApply prepends two more return addresses to this list, the usual return address to containerB.opApply, and its corresponding break return (prepend because the last return addressed pushed must correspond with the immediate containing scope of the called delegate, but if the delegate knows about outer scopes then it can return to those). Now the innerLoop delegate has four return addresses: return to containerB.opApply normally (continue innerLoop), return to containerB.opApply's cleanup code (break innerLoop), return to containerA.opApply normally (continue outerLoop), and return to containerA.opApply's cleanup code (break outerLoop). So break/continue works for all cases. (Of course, containerB.opApply doesn't actually just prepend return addresses to what the outerLoop delegate passes in, since when the innerLoop delegate wants to break outerLoop, it needs to cleanup the stack frames of the intervening call to containerB.opApply too. So containerB.opApply needs to insert its own cleanup code into the return address chain.) This is, at least, the *conceptual* aspect of things. In the actual implementation, the compiler may use the current scheme (return an int to indicate which return is desired) instead of doing what amounts to reinventing stack unwinding, but the important point is, this should be transparent to user code. As far as the user is concerned, they just call the delegate normally, no need to check return codes, etc., with the understanding that the said delegates have multiple return addresses. The compiler inserts the necessary scaffolding, checking for int returns, etc., to actually implement the concept. T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan
Apr 29 2012
prev sibling next sibling parent Don Clugston <dac nospam.com> writes:
On 30/04/12 05:45, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 04:40:37PM +0200, Jacob Carlborg wrote:
 [...]
 * Do-while loops, how useful are those actually?


I grepped through the DMD source once, looking for how often Walter uses do..while. The answer: exactly zero.
 OK, that got me all riled up about looping constructs, and now I'm
 provoked to rant:

 Since the advent of structured programming, looping constructs have
 always been somewhat b0rken. Yes they worked very well, they are clean,
 powerful, gets rid of almost all cases of needing goto's, etc.. But the
 point of a loop is that *the entry point does not always correspond with
 the exit point (where the loop condition is tested)*. The problem with
 both do-loops and while-loops is that they are just straitjacketed
 versions of a more general looping construct.

Completely agree. Forth is one of the few languages which got it right. BEGIN .... cond WHILE ... REPEAT
Apr 30 2012
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 30.04.2012 7:45, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 04:40:37PM +0200, Jacob Carlborg wrote:

 So you might say, OK, just write this then:

 	for(;;) {
 		auto line = nextLine();
 		if (eof())
 			break;
 		processLine(line);
 	}

 Well, finally you have something sane. The loop condition now correctly
 appears in the middle of the loop body, which is where it should've been
 all along. Only problem is, writing for(;;) is misleading, because
 you're not looping indefinitely, there's precisely one exit condition.
 Conveying intent is very important in writing good code, and this code
 breaks that principle.

 So really, what is needed is a sane looping construct that unifies while
 loops, do-loops, and exit-in-the-middle loops. Something like this:

 	loop {
 		// first part of loop body
 	} exitWhen(!loopCondition) {
 		// second part of loop body
 	}

You'd love PL/SQL. :) -- Dmitry Olshansky
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Don Clugston:

 * Do-while loops, how useful are those actually?


I grepped through the DMD source once, looking for how often Walter uses do..while. The answer: exactly zero.

In my code I use one do-while about every 20 or 30 loops, so they aren't very common, but are useful. If I need a random 2D point on a disk, one method to produce it is by rejection, I use a do-while loop, I extract two coordinates in a square, and then test if they are inside the disk, otherwise I loop. But I have a problem with D-style do-while loops, that some time ago I have discussed a bit in D.learn: I can't use them like this, because the variables defined inside the loop are not visible in the loop test: do { // ... const x = compute something } while (predicate(x)); I have to use this, that is less handy: T x; do { // ... x = compute something } while (predicate(x)); Bye, bearophile
Apr 30 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-30 05:45, H. S. Teoh wrote:

 While personally, I like the idea of being able to create new infix
 operators, it will cause too big a change to D syntax, and probably
 cause lots of breakages with existing code, as well as make the
 lexer/parser much harder to implement (given the existing D features).

 You also then have to deal with operator precedence between arbitrary
 user-defined operators, which is non-trivial in general (though it's
 workable if you impose some constrains -- but it's probably way beyond
 the scope of D2 or even D3).

Yes, a language would basically need to be designed with this in mind from the start. That's what I'm thing sometimes, D could have gone down some other road in some cases but it's way too late to change it now. -- /Jacob Carlborg
Apr 30 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 05:45 AM, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 04:40:37PM +0200, Jacob Carlborg wrote:
 [...]

 So really, what is needed is a sane looping construct that unifies while
 loops, do-loops, and exit-in-the-middle loops. Something like this:

 	loop {
 		// first part of loop body
 	} exitWhen(!loopCondition) {
 		// second part of loop body
 	}

 It doesn't have to be this exact syntax, but the point is that you need
 to be able to express loop exits from the middle of a loop body without
 needing to resort to for(;;) and break, when the loop is a good ole
 simple loop with a single entry point and a single exit point. (More
 complex loops that need continue's and break's are, well, more complex,
 so it's OK to sprinkle if conditions in them like we do now.)

 </rant>

do{ // ... }while(cond){ // ... } I think the scoping rules of the do-while loop should be fixed such that the loop condition can refer to loop-local variables. Violates C backwards compatibility though...
 [...]
 * Infix notation for calling any method taking one argument
 * Basically any symbol is allowed in method names

 That is:

 1 + 2
 foo bar foo_bar

 Would be translated to:

 1.+(2)
 foo.bar(foo_bar)

 That is a very general way to handle operators and let the user
 create new operators, not just overloading existing ones.

While personally, I like the idea of being able to create new infix operators, it will cause too big a change to D syntax, and probably cause lots of breakages with existing code, as well as make the lexer/parser much harder to implement (given the existing D features).

Should be trivial. (The parser can just defer operator precedence resolution to the analysis phase if necessary, and otherwise it is very simple anyway.)
 You also then have to deal with operator precedence between arbitrary
 user-defined operators, which is non-trivial in general (though it's
 workable if you impose some constrains

I kinda like the Scala-approach.
 -- but it's probably way beyond the scope of D2 or even D3).

An issue is that it clashes with eg. a+***ptrtoptrtoptrtodata.
Apr 30 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 29 April 2012 at 12:26:13 UTC, David Nadlinger wrote:
  - Anonymous nested classes: They might be useful in Java, 
 particularly in older incarnations, but not so much in D – 
 never used them.

I never used these until very recently. A couple weeks ago, I wanted to do some kind of range adapter kinda like Phobos does with the anon structs... but I wanted it to work with runtime too. So, I made an interface with empty, front, popFront, and then pulled out the old "return new class ByChunkRange" for the first time. I never expected that I'd use it, but it was nice to have for that time when I did decide I wanted it. That's my biggest concern with saying we have too many features. We might not use them often, but it would suck to say "that would be perfect" just to find it was removed later.
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 10:28:47AM +0200, SomeDude wrote:
 On Sunday, 29 April 2012 at 08:13:53 UTC, Nick Sabalausky wrote:
There will still be sugar in the compiler so they appear to be
builtins.  When the switch happens, I'm sure it'll be transparent -
average users probably won't even notice. It's just that "behind the
scenes" their implementation will move from DMD to Druntime.

Hmmm, sounds nice, but bolting the language with the standard library is very risky (and a rather bad idea imho). Unless there is a very lightweight minimalistic core for Phobos (something which I advocate), you bolt a heavyweight library to your language, and that's not good.

Please note that the AA implementation will be moving into druntime, NOT phobos. The compiler already depends on a bunch of stuff in druntime (the GC being a prime example, and the Object class being another). And every time you write 'typeid'? That's druntime code too. T -- It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.
Apr 29 2012
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
On 28.04.2012 20:47, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

* The >>> operator, which does nothing except introduce bugs (It does NOT perform an unsigned shift). * package. I have no idea how a failed Java experiment got incorporated into D. * the zoo of parameter passing options * Most of the __traits are useless and redundant.
Apr 29 2012
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 15:50:54 UTC, Don wrote:
 * package. I have no idea how a failed Java experiment got 
 incorporated into D.

+1, forgot to mention that one. David
Apr 29 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 29-04-2012 22:24, SomeDude wrote:
 On Sunday, 29 April 2012 at 18:47:11 UTC, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 18:39:49 UTC, SomeDude wrote:
 What's wrong with packages ?

Nothing – this is about the »package« protection level, not packages. ;) David

Ah ok. But I'm not sure what's wrong with the package protection level either, actually.

Yes, me neither. And I have found many cases in my code where using it actually makes sense and helps encapsulation. -- - Alex
Apr 29 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Don:

 * package. I have no idea how a failed Java experiment got 
 incorporated into D.

Weren't Java designers thinking about adding superpackages too to Java?
 * the zoo of parameter passing options

Please explain, what do you mean? Bye, bearophile
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 17:05:19 UTC, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 15:50:54 UTC, Don wrote:
 * package. I have no idea how a failed Java experiment got 
 incorporated into D.

+1, forgot to mention that one. David

What's wrong with packages ?
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 18:39:49 UTC, SomeDude wrote:
 What's wrong with packages ?

Nothing – this is about the »package« protection level, not packages. ;) David
Apr 29 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/29/2012 08:08 PM, Manu wrote:
 On 29 April 2012 18:50, Don <nospam nospam.com
 <mailto:nospam nospam.com>> wrote:

     On 28.04.2012 20:47, Walter Bright wrote:

         Andrei and I had a fun discussion last night about this
         question. The
         idea was which features in D are redundant and/or do not add
         significant
         value?

         A couple already agreed upon ones are typedef and the cfloat,
         cdouble
         and creal types.

         What's your list?


     * The >>> operator, which does nothing except introduce bugs (It
     does NOT perform an unsigned shift).


 What does it do? I use this all over the place, I assumed it worked...
 maybe I have bugs?

It does work, but it behaves in unexpected ways for narrow signed integers (short/byte) because it sign-extends them before shifting. It works fine with int/uint/long/ulong.
     * Most of the __traits are useless and redundant.


 Which traits are useless and redundant? I'm actually finding the set is
 incomplete, and there are some missing (parameter list introspection,
 current scope/object identification, current module/package)

+1.
Apr 29 2012
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 29.04.2012 20:08, schrieb Manu:
 On 29 April 2012 18:50, Don <nospam nospam.com
 [...]
     * package. I have no idea how a failed Java experiment got
     incorporated into D.


 package confuses me, it's poorly documented. What are the protections
 between packages, sub-packages. Can parent packages see sub-package
 contents? vice-versa?

I've always assume that package is similar to what is available in another module based languages. Where you have a library (package) that is composed of several separated modules. In certain scenarios, you want to have symbols that are private to the library, but need to be marked public so that each module, that is part of the library, is able to see them. So you mark those symbols as package level access. This is usually done in "programming in the large" projects. Some examples where I think this concept might be visible, - .NET Modules (internal is used for visibility accross .dll) - default package access for Java common namespaces scattered across several jar files - Ada limited and child packages - Delphi packages -- Paulo
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 18:47:11 UTC, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 18:39:49 UTC, SomeDude wrote:
 What's wrong with packages ?

Nothing – this is about the »package« protection level, not packages. ;) David

Ah ok. But I'm not sure what's wrong with the package protection level either, actually.
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 21:06:10 UTC, Alex Rønne Petersen 
wrote:
 On 29-04-2012 22:24, SomeDude wrote:
 Ah ok. But I'm not sure what's wrong with the package 
 protection level
 either, actually.

Yes, me neither. And I have found many cases in my code where using it actually makes sense and helps encapsulation.

See the Java discussion on »superpackages« – quite often, you want to share stuff in mylibrary.subpackage with the rest of mylibrary, but not the world. David
Apr 29 2012
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 29/04/2012 19:08, Manu wrote:
 current module/package

http://dlang.org/phobos/std_traits#packageName http://dlang.org/phobos/std_traits#moduleName -- Robert http://octarineparrot.com/
Apr 29 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 17:50:48 Don wrote:
 * package. I have no idea how a failed Java experiment got incorporated
 into D.

Really? In some cases, it's indispensable. For instance, once std.datetime has been split up, it will require it, or it would have duplicate a bunch of implementation-specific stuff which has no business in the public API. - Jonathan M Davis
Apr 29 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 30/04/2012 05:12, Kapps a Ă©crit :
 On Monday, 30 April 2012 at 01:08:28 UTC, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 17:50:48 Don wrote:
 * package. I have no idea how a failed Java experiment got incorporated
 into D.

Really? In some cases, it's indispensable. For instance, once std.datetime has been split up, it will require it, or it would have duplicate a bunch of implementation-specific stuff which has no business in the public API. - Jonathan M Davis

It's entirely dependent on your coding style. For example, when you look at Phobos you rarely (if ever?) see package functions. This is because it's entirely module based with a strong degree of separation between modules. However, for someone coming from C#, removing package would be awful. I personally use package quite often. For the most part, I stick to one major class per file, and separate things across library. There are plenty of things that I want other classes in the package/static-library to use, but don't want to expose to the public, and thus use package for.

Phobos is a really good example. Modules tend to become more and more fat. And to split them up, package is mandatory.
Apr 30 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Monday, 30 April 2012 at 01:08:28 UTC, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 17:50:48 Don wrote:
 * package. I have no idea how a failed Java experiment got 
 incorporated
 into D.

Really? In some cases, it's indispensable. For instance, once std.datetime has been split up, it will require it, or it would have duplicate a bunch of implementation-specific stuff which has no business in the public API. - Jonathan M Davis

It's entirely dependent on your coding style. For example, when you look at Phobos you rarely (if ever?) see package functions. This is because it's entirely module based with a strong degree of separation between modules. However, for someone coming from C#, removing package would be awful. I personally use package quite often. For the most part, I stick to one major class per file, and separate things across library. There are plenty of things that I want other classes in the package/static-library to use, but don't want to expose to the public, and thus use package for.
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 30 April 2012 at 01:08:28 UTC, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 17:50:48 Don wrote:
 * package. I have no idea how a failed Java experiment got 
 incorporated
 into D.

Really? In some cases, it's indispensable. For instance, once std.datetime has been split up, it will require it, or it would have duplicate a bunch of implementation-specific stuff which has no business in the public API.

But what happens if std.datetime grows so large that you want to have e.g. a std.datetime.system package, the content of which is accessible from std.datetime.*, but not the rest of the world? This is not an artificial problem, e.g. consider Thrift, where I have e.g. thrift.internal.endian (predating endian stuff in Phobos) which is used from modules in thrift.async, thrift.server, and thrift.protocol, or thrift.internal.socket (containing some more OS abstractions than std.socket does), which is used from modules in thrift.async, thrift.server, and thrift.transport, but both are not part of the public API. The logical »package« to restrict access to would be »thrift.*« here, but there is no way to restrict access to that, I have to resort to hoping users understand that they should not use »thrift.internal.xyz« directly. Phobos has the same problem with std.internal. I think in Java this problem was the reason for »super packages« to be discussed which (I think, haven't followed it the developments closely) ended up being incorporated in the upcoming Module System feature. David
Apr 29 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-29 20:08, Manu wrote:

 package confuses me, it's poorly documented. What are the protections
 between packages, sub-packages. Can parent packages see sub-package
 contents? vice-versa?

As far as I know it works like this: pack |- pack1 |- foo.d |- bar.d |- pack2 |- a.d |- pack3 |- b.d |- c.d // pack.pack1.foo package int x = 3; // pack.pack1.bar x = 4; // this is fine since it's in the same package. // pack.pack1.pack2.a x = 5; // error, cannot access package protected variable. // pack.pack3.b x = 6; // error, cannot access package protected variable. // pack.c x = 7; // error, cannot access package protected variable. Oh, and "package" is non-virtual, for some reason. -- /Jacob Carlborg
Apr 29 2012
prev sibling next sibling parent reply Don Clugston <dac nospam.com> writes:
On 29/04/12 20:08, Manu wrote:
 On 29 April 2012 18:50, Don <nospam nospam.com
 <mailto:nospam nospam.com>> wrote:

     On 28.04.2012 20:47, Walter Bright wrote:

         Andrei and I had a fun discussion last night about this
         question. The
         idea was which features in D are redundant and/or do not add
         significant
         value?

         A couple already agreed upon ones are typedef and the cfloat,
         cdouble
         and creal types.

         What's your list?


     * The >>> operator, which does nothing except introduce bugs (It
     does NOT perform an unsigned shift).


 What does it do? I use this all over the place, I assumed it worked...
 maybe I have bugs?

It works only for two types: int and long. For everything else, it is identical to >> So for short and byte, and in generic code, it's ALWAYS a bug.
Apr 30 2012
parent reply Don Clugston <dac nospam.com> writes:
On 30/04/12 12:27, Manu wrote:
 On 30 April 2012 10:32, Don Clugston <dac nospam.com
 <mailto:dac nospam.com>> wrote:

     On 29/04/12 20:08, Manu wrote:

         On 29 April 2012 18:50, Don <nospam nospam.com
         <mailto:nospam nospam.com>
         <mailto:nospam nospam.com <mailto:nospam nospam.com>>> wrote:


             On 28.04.2012 20:47, Walter Bright wrote:

                 Andrei and I had a fun discussion last night about this
                 question. The
                 idea was which features in D are redundant and/or do not add
                 significant
                 value?

                 A couple already agreed upon ones are typedef and the
         cfloat,
                 cdouble
                 and creal types.

                 What's your list?


             * The >>> operator, which does nothing except introduce bugs (It
             does NOT perform an unsigned shift).


         What does it do? I use this all over the place, I assumed it
         worked...
         maybe I have bugs?


     It works only for two types: int and long.
     For everything else, it is identical to >>
     So for short and byte, and in generic code, it's ALWAYS a bug.


 O_O
 Is that intentional? Or is it... a bug?
 I smiled when I saw >>> in the language, I appreciate its presence. It's
 not necessary, but it cuts down on some ugly explicit casting (which
 theoretically makes generic code simpler).

It's not a bug, it's a design flaw. The buggy behaviour is explicitly tested in the test suite. The problem is that the C promotion rules also apply, just as for >> and <<. But they are fundamentally incompatible with unsigned shift. So short and byte get promoted to int *by sign extension*, then the int gets an unsigned shift. Which means that the short or byte gets a signed shift instead of an unsigned one. I used to use >>> in my code, because as you say, it is a nice idea, but after having a few bugs with short, and working out what the semantics actually were, I suddenly realized it was a landmine, and I removed every instance of it from my code. (cast(ulong)x) >> 3 is safer than x >>> 3, unfortunately.
Apr 30 2012
next sibling parent ponce <spam spam.org> writes:
Le 30/04/2012 14:44, Don Clugston a Ă©crit :
 It's not a bug, it's a design flaw. The buggy behaviour is explicitly
 tested in the test suite.
 The problem is that the C promotion rules also apply, just as for >> and
 <<. But they are fundamentally incompatible with unsigned shift.
 So short and byte get promoted to int *by sign extension*,
 then the int gets an unsigned shift.
 Which means that the short or byte gets a signed shift instead of an
 unsigned one.

Thanks for pointing that out. Sadly, it makes some sense with the C integer promotion rules.
May 01 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 02:44 PM, Don Clugston wrote:
 (cast(ulong)x) >> 3 is safer than x >>> 3, unfortunately.

In what way is it safer? void main() { short x = -1; assert((cast(ulong)x) >> 3 == cast(long)x >>> 3); }
May 01 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0023544713240f493e04bee2e88c
Content-Type: text/plain; charset=UTF-8

On 30 April 2012 10:32, Don Clugston <dac nospam.com> wrote:

 On 29/04/12 20:08, Manu wrote:

 On 29 April 2012 18:50, Don <nospam nospam.com
 <mailto:nospam nospam.com>> wrote:


    On 28.04.2012 20:47, Walter Bright wrote:

        Andrei and I had a fun discussion last night about this
        question. The
        idea was which features in D are redundant and/or do not add
        significant
        value?

        A couple already agreed upon ones are typedef and the cfloat,
        cdouble
        and creal types.

        What's your list?


    * The >>> operator, which does nothing except introduce bugs (It
    does NOT perform an unsigned shift).


 What does it do? I use this all over the place, I assumed it worked...
 maybe I have bugs?

It works only for two types: int and long. For everything else, it is identical to >> So for short and byte, and in generic code, it's ALWAYS a bug.

O_O Is that intentional? Or is it... a bug? I smiled when I saw >>> in the language, I appreciate its presence. It's not necessary, but it cuts down on some ugly explicit casting (which theoretically makes generic code simpler). --0023544713240f493e04bee2e88c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 30 April 2012 10:3= 2, Don Clugston <span dir=3D"ltr">&lt;<a href=3D"mailto:dac nospam.com" tar= get=3D"_blank">dac nospam.com</a>&gt;</span> wrote:<br><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"> On 29/04/12 20:08, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 29 April 2012 18:50, Don &lt;<a href=3D"mailto:nospam nospam.com" target= =3D"_blank">nospam nospam.com</a><br> &lt;mailto:<a href=3D"mailto:nospam nospam.com" target=3D"_blank">nospam no= spam.com</a>&gt;&gt; wrote:<div class=3D"im"><br> <br> =C2=A0 =C2=A0On 28.04.2012 20:47, Walter Bright wrote:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0Andrei and I had a fun discussion last night ab= out this<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0question. The<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0idea was which features in D are redundant and/= or do not add<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0significant<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0value?<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0A couple already agreed upon ones are typedef a= nd the cfloat,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0cdouble<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0and creal types.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0What&#39;s your list?<br> <br> <br></div> =C2=A0 =C2=A0* The &gt;&gt;&gt; operator, which does nothing except introd= uce bugs (It<br> =C2=A0 =C2=A0does NOT perform an unsigned shift).<br> <br> <br> What does it do? I use this all over the place, I assumed it worked...<br> maybe I have bugs?<br> </blockquote> <br> It works only for two types: int and long.<br> For everything else, it is identical to &gt;&gt;<br> So for short and byte, and in generic code, it&#39;s ALWAYS a bug.<br> </blockquote></div><div class=3D"gmail_extra"><br></div>O_O</div><div class= =3D"gmail_extra">Is that intentional? Or is it... a bug?</div><div class=3D= "gmail_extra">I smiled when I saw &gt;&gt;&gt; in the language, I appreciat= e its presence. It&#39;s not necessary, but it cuts down on some ugly expli= cit casting (which theoretically makes generic code simpler).</div> --0023544713240f493e04bee2e88c--
Apr 30 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 30 April 2012 at 12:35:24 UTC, deadalnix wrote:
 Phobos is a really good example. Modules tend to become more 
 and more fat. And to split them up, package is mandatory.

Except that it doesn't work if the module you want to refactor into a sub-package already used »package«… David
Apr 30 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--002354470e3c1f87bc04bed53aa4
Content-Type: text/plain; charset=UTF-8

On 29 April 2012 18:50, Don <nospam nospam.com> wrote:

 On 28.04.2012 20:47, Walter Bright wrote:

 Andrei and I had a fun discussion last night about this question. The
 idea was which features in D are redundant and/or do not add significant
 value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal types.

 What's your list?

* The >>> operator, which does nothing except introduce bugs (It does NOT perform an unsigned shift).

What does it do? I use this all over the place, I assumed it worked... maybe I have bugs?
 * package. I have no idea how a failed Java experiment got incorporated
 into D.

package confuses me, it's poorly documented. What are the protections between packages, sub-packages. Can parent packages see sub-package contents? vice-versa? * Most of the __traits are useless and redundant.

Which traits are useless and redundant? I'm actually finding the set is incomplete, and there are some missing (parameter list introspection, current scope/object identification, current module/package) --002354470e3c1f87bc04bed53aa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 29 April 2012 18:5= 0, Don <span dir=3D"ltr">&lt;<a href=3D"mailto:nospam nospam.com" target=3D= "_blank">nospam nospam.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> <div class=3D"im">On 28.04.2012 20:47, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Andrei and I had a fun discussion last night about this question. The<br> idea was which features in D are redundant and/or do not add significant<br=

<br> A couple already agreed upon ones are typedef and the cfloat, cdouble<br> and creal types.<br> <br> What&#39;s your list?<br> </blockquote> <br></div> * The &gt;&gt;&gt; operator, which does nothing except introduce bugs (It d= oes NOT perform an unsigned shift).<br></blockquote><div><br></div><div>Wha= t does it do? I use this all over the place, I assumed it worked... maybe I= have bugs?</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"> * package. I have no idea how a failed Java experiment got incorporated int= o D.<br></blockquote><div><br></div><div>package confuses me, it&#39;s poor= ly documented. What are the protections between packages, sub-packages. Can= parent packages see sub-package contents? vice-versa?</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">* Most of the __traits are us= eless and redundant.<br></blockquote><div><br></div><div>Which traits are u= seless and redundant? I&#39;m actually finding the set is incomplete, and t= here are some missing (parameter list introspection, current scope/object i= dentification, current module/package)</div> </div></div> --002354470e3c1f87bc04bed53aa4--
Apr 29 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/29/12, David Nadlinger <see klickverbot.at> wrote:
 As for r"", every time I
 actually need WysiwigString, I use backticks, because such
 strings often contain quotes anyway.

IIRC I think the reason for this might be that some keyboards don't have the backtick key, or something like that.
 Regarding TokenString(i.e.
 q{}) .. The problem is that
 can't just =BBinterrupt=AB q{}s strings to do something like
 =BBq{=85} ~ identifierName ~ q{=85}=AB,

I typically use format for these purposes, e.g.: string x =3D format(q{ void %s() { } }, "foo"); Works fairly well for me.
   - Concatenation of adjacent strings: Also an anti-feature, imho.

Absolutely!
   - =BBShort=AB floating point literals like .4 instead of 0.4 and
 4. instead of 4.0 =96 the saved characters are not worth the
 syntax special cases, especially w.r.t. UFCS.

I think those are already deprecated? Or they're about to be anyway.
   - shared: TLS by default is great, but only __gshared is really
 usable right now.

Yep, and Phobos doesn't deal with shared all that well either. E.g. format() doesn't work on shared variables (http://d.puremagic.com/issues/show_bug.cgi?id=3D7036).
Apr 29 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/29/12, Jacob Carlborg <doob me.com> wrote:
 In principle I agree with you. But in practice this doesn't always work.
 Take this for example:
 Prints "0" and "1" as expected. If we now change "point" to a property
 like this:
 It will now print "0" and "0". This is a silently breaking change. Sure
 you can change "point" to return by reference..

This is a great point and an issue I've ran into and talked about before. The compiler really ought to try and convert a call like this: foo.property++; foo.property+=10; into e.g.: foo.property = foo.property.opAdd(1); foo.property = foo.property.opAdd(10); It would make for some really nice APIs if this feature was available. Otherwise I have to resort to template magic and delegate calls such as: class Widget { Notify!Point pos; this() { pos.init(&posSet); } // if pos changes, invoke posChange void posChange(ref Point newPos) { newPos.normalize(); } // e.g. if out of bounds } Unfortunately that template broke in an earlier compiler regression that I haven't noticed until recently (http://d.puremagic.com/issues/show_bug.cgi?id=7991)
Apr 29 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

   - »Short« floating point literals like .4 instead of 0.4 
 and
 4. instead of 4.0 – the saved characters are not worth the
 syntax special cases, especially w.r.t. UFCS.

I think those are already deprecated? Or they're about to be anyway.

I have asked for it, but currently there are no plans in deprecating them, please vote if you agree and you have free votes left (already 7 votes! It's a lot): http://d.puremagic.com/issues/show_bug.cgi?id=6277 Bye, bearophile
Apr 29 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/29/12, bearophile <bearophileHUGS lycos.com> wrote:
 I have asked for it, but currently there are no plans in
 deprecating them, please vote if you agree and you have free
 votes left (already 7 votes! It's a lot):

Well I assumed they're on the way to deprecation when I've read this: http://dlang.org/changelog.html#new2_058: "Allow 1.userproperty syntax. NOTE: 1.f is no longer a float literal, add a 0."
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 12:26:13 UTC, David Nadlinger wrote:
 On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
 What's your list?

My personal list of features I could easily live without – some of these might be controversial, but yes, I have written non-trivial amounts of code in both D1 and D2:

What I forgot to mention: - VersionCondition: Just provide a mechanism to map command line flags to constants, probably in a magic »version« namespace, and use static if (e.g. »version (Foo)« -> »static if (version.Foo)«, »version (unittest)« -> »static if (unittest)«). - DebugCondition: Hardly used in practice, at least not in ways that couldn't easily be replaced with a static if (resp. version). It is a frequent source of confusion for newcomers that -debug is orthogonal to -O/-release, and I'm not too fond of the purity »escape hatch« built in (why not just use casts in those rare cases?). David
Apr 29 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 I'm not sure that's valid outside a function, though.

It doesn't work outside functions. More info: http://d.puremagic.com/issues/show_bug.cgi?id=4085 Bye, bearophile
Apr 29 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/29/12, Alex R=F8nne Petersen <xtzgzorex gmail.com> wrote:
 Next up is the issue of op-assign operations. In D, you can't do:

 obj.foo +=3D 1;
 obj.foo++;

 while in C#, you can (it results in a get -> add 1 -> set and get -> inc
 -> set, etc).

It's great to see another (successful) language implemented this. Do we have a proposal open for this somewhere?
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 20:10:20 UTC, Alex Rønne Petersen 
wrote:
 On 29-04-2012 01:49, SomeDude wrote:
 [snip wall of text]

C++11 has range-based for (which is basically foreach).
 [snip wall of text]


This is off-topic, but in general, please try to quote only the relevant parts of the message you are replying to (you just quoted the whole long message three times in full). David
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 20:00:27 UTC, Alex Rønne Petersen 
wrote:
 Let's get a standard package manager that we either advocate on 
 dlang.org or include in the releases before we start talking 
 about reducing the amount of modules in Phobos.

Don't get me wrong. I don't want to reduce the amount of modules in Phobos. I think it's a great standard library. A little bit buggy in some places, and lacks a few important features (that are in the review queue), but great overall. I fear the risk with a package system is, having some parts of Phobos not being correctly maintained with time. And I want to be able to have the whole thing with a single download. No, my concern was, for smaller applications, in embedded systems for instance (Android, iOS, etc), there is not really a small basic library. So I would think of a two level standard library, one on top of the other. OTOH, Jonathan Davis made the remark that we can always use the C lib and its bindings, so this mostly satisfies my concern.
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 28 April 2012 at 23:41:29 UTC, Peter Alexander wrote:
 But in D the main purpose of "pure" is not as optimization 
 tool, but more as a tool to enforce a better coding style, 
 that makes code understanding (and testing simpler), and helps 
 avoid some bugs, coming from using variables from outer scopes.

True, but I'm quite happy to write pure functions without the static checking. I do not believe that the safety provided by the static checks outweighs the development cost of ensuring you have the correct qualifiers everywhere.

Maybe you don't feel the benefit because you have less bugs in multithreaded applications than you would without, but you can't really know unless you do write the same code without ? Or something like that. :o) Anyway, I have the feeling that it's very hard to quantify the benefits of adding purity vs not having it. The benefits are both very theoretical, and practically verified in functional languages everyday. But knowing that the compiler *guarantees* certain properties and that some classes of errors cannot happen helps coding with a certain peace of mind, i.e you *know* that some bad things can't happen. So it's a little pain to satisfy the static checking of the compiler, but it's still much better than having to debug random race conditions that happen once in a while in production and are thus very hard to reproduce, and it does certainly help when you have to *ensure* that your critical code can never hang.
Apr 29 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 29 April 2012 at 19:19:51 UTC, David Nadlinger wrote:
 On Sunday, 29 April 2012 at 12:26:13 UTC, David Nadlinger wrote:
 What I forgot to mention:
  - VersionCondition: Just provide a mechanism to map command 
 line flags to constants, probably in a magic »version« 
 namespace, and use static if (e.g. »version (Foo)« -> 
 »static if (version.Foo)«, »version (unittest)« -> »static 
 if (unittest)«).

It sounds indeed nice, but I prefer convention over configuration. Experience has shown that it makes things simpler.
Apr 29 2012
prev sibling next sibling parent "akaz" <nemo utopia.com> writes:
On Saturday, 28 April 2012 at 19:58:03 UTC, foobar wrote:
 * di files - a library should encapsulate all the info required
 to use it. Java Jars, .Net assemblies and even old school; 
 Pascal
 units all solved this long ago.

I strongly support this.
Apr 29 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 29 April 2012 at 21:18:40 UTC, deadalnix wrote:
 Le 29/04/2012 03:06, bearophile a Ă©crit :
 Jonathan M Davis:

 * foreach_reverse is essentially redudant at this point (not 
 to mention
 confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...

This is an implementation issue and shouldn't be an argument for language design.

The 'sufficiently smart compiler' argument is old and invalid. Please do not use it.
Apr 29 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 29 April 2012 at 21:23:41 UTC, SomeDude wrote:
 On Sunday, 29 April 2012 at 19:19:51 UTC, David Nadlinger wrote:
 What I forgot to mention:
 - VersionCondition: Just provide a mechanism to map command 
 line flags to constants, probably in a magic »version« 
 namespace, and use static if (e.g. »version (Foo)« -> 
 »static if (version.Foo)«, »version (unittest)« -> 
 »static if (unittest)«).

It sounds indeed nice, but I prefer convention over configuration. Experience has shown that it makes things simpler.

What exactly does this have to do with »convention over configuration«? The big problem with version conditionals is that they introduce a heavily restricted subset of static if, i.e. a whole new language construct, for questionable benefits. David
Apr 29 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074d75863738004bed88fb1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 29 April 2012 23:00, Alex R=C3=B8nne Petersen <xtzgzorex gmail.com> wrot=
e:

 On 28-04-2012 23:18, SomeDude wrote:

 Yeah, but core language AA are so useful it would be a MAJOR mistake to
 remove them. In Python too, you could put the AA in the libraries. Yet
 everybody uses the AA that are in the language.

 Where I DO agree with you is, Phobos should be a two level library, i.e
 a minimalistic library, with about the same feature set as the standard
 C library + multithreading, and a superset with the full range of
 features (ranges, algorithms, etc). I've already advocated it somewhere
 else.

Let's get a standard package manager that we either advocate on dlang.org=

 amount of modules in Phobos.

Oh hell yes! I have exciting dreams of something like this every other night ;) --20cf3074d75863738004bed88fb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 29 April 2012 23:0= 0, Alex R=C3=B8nne Petersen <span dir=3D"ltr">&lt;<a href=3D"mailto:xtzgzor= ex gmail.com" target=3D"_blank">xtzgzorex gmail.com</a>&gt;</span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"> On 28-04-2012 23:18, SomeDude wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Yeah, but core language AA are so useful it = would be a MAJOR mistake to<br> remove them. In Python too, you could put the AA in the libraries. Yet<br> everybody uses the AA that are in the language.<br> <br> Where I DO agree with you is, Phobos should be a two level library, i.e<br> a minimalistic library, with about the same feature set as the standard<br> C library + multithreading, and a superset with the full range of<br> features (ranges, algorithms, etc). I&#39;ve already advocated it somewhere= <br> else.<br> </blockquote> <br> Let&#39;s get a standard package manager that we either advocate on <a href= =3D"http://dlang.org" target=3D"_blank">dlang.org</a> or include in the rel= eases before we start talking about reducing the amount of modules in Phobo= s.</blockquote> <div><br></div><div>Oh hell yes! I have exciting dreams of something like t= his every other night ;)</div></div></div> --20cf3074d75863738004bed88fb1--
Apr 29 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter:

 What's your list?

This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter & Andrei? Bye, bearophile
Apr 29 2012
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
I would say  many of the discussion items are to be fixed in a D version 
"break the
world" to be done when D finally becomes famous, similar to Python 3000 
plans.

Until then the focus should be in fixing the open bugs, deviations to the 
TDPL, and
improving available tools and frameworks.

What is the point of having a perfect systems programming language if no one 
uses it?

--
Paulo


"bearophile"  wrote in message news:tfbtvfccnxluzbuxofot forum.dlang.org...

Walter:

 What's your list?

This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter & Andrei? Bye, bearophile
Apr 30 2012
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 30.04.2012 10:55, Jonathan M Davis wrote:
 On Monday, April 30, 2012 01:41:45 bearophile wrote:
 Walter:
 What's your list?

This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter& Andrei?

Honestly, I don't think that you _can_ take much from this thread other than the fact that pretty _every_ feature is wanted and used by someone, even if other people hate it. Pretty much every feature listed as undesirable by someone was listed as desirable by someone else.

foreach_reverse, comma operator, etc.
 As for TODOs, the impression that I got from Walter's post was that he wanted
 to know what people thought out of curiosity or just for "lessons learned"
 from the design process of D and not that he was really looking to remove
 anything from the language. So, I don't think that it was ever his intention
 to create a TODO list from this (though I could be wrong). There may be some
 minor things that get changed (such as making it so that adjacent string
 literals don't get automatically concatenated), but I don't think that D is
 really going to have any of its features removed at this point.

 - Jonathan M Davis

-- Dmitry Olshansky
Apr 30 2012
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 01:41, bearophile wrote:
 Walter:

 What's your list?

This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter & Andrei? Bye, bearophile

I think the one thing there is universal agreement on is that the comma operator has to go. -- - Alex
Apr 30 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 30/04/2012 18:13, Peter Alexander a Ă©crit :
 On Monday, 30 April 2012 at 15:35:19 UTC, H. S. Teoh wrote:
 So far, I've not seen a single response in favor of keeping the comma
 operator.

Very few want it, but as a practicality, it would be unwise to remove it (would break an awful lot of code).

Some have proposed that comma operator could create tuples. If void members in tuples are automagically skipped, this won't break that many code. A first step in that direction would be to deprecate comma expression where expressions before the last one have not type void.
Apr 30 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 05:36 PM, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 11:55:43PM -0700, Jonathan M Davis wrote:
 [...]
 Honestly, I don't think that you _can_ take much from this thread
 other than the fact that pretty _every_ feature is wanted and used by
 someone, even if other people hate it. Pretty much every feature
 listed as undesirable by someone was listed as desirable by someone
 else.

So far, I've not seen a single response in favor of keeping the comma operator. T

I think I use it about every 60 lines of code. Also, I don't think it should be removed for the sake of removing it. If it is removed, the syntax should be reused.
Apr 30 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 08:46 PM, Timon Gehr wrote:
 On 04/30/2012 05:36 PM, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 11:55:43PM -0700, Jonathan M Davis wrote:
 [...]
 Honestly, I don't think that you _can_ take much from this thread
 other than the fact that pretty _every_ feature is wanted and used by
 someone, even if other people hate it. Pretty much every feature
 listed as undesirable by someone was listed as desirable by someone
 else.

So far, I've not seen a single response in favor of keeping the comma operator. T

I think I use it about every 60 lines of code.

(outside for)
 Also, I don't think it
 should be removed for the sake of removing it. If it is removed, the
 syntax should be reused.

Apr 30 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 30/04/2012 22:44, bearophile a Ă©crit :
 Timon Gehr:

 I think I use it about every 60 lines of code. Also, I don't think it
 should be removed for the sake of removing it. If it is removed, the
 syntax should be reused.

Commas do cause some bugs, so maybe they are worth restricting (further) even if their syntax doesn't get reused. Bye, bearophile

+1 Looking for a , instead of a ; is really painful. It doesn't occur often, but when it does, you remember it for quite a long time.
Apr 30 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/12 5:15 AM, bearophile wrote:
 Jonathan M Davis:

 Honestly, I don't think that you _can_ take much from this thread
 other than

I don't agree, I see some recurring patterns. People have spent energy and time to write lot of answers in this thread, some good answer bits too, so I expect such work to not let be fully wasted. Asking for opinions, receiving lot of them, and then ignoring them all is not a good way to run a community.

It's a bit inappropriate to bind Walter to such a social contract upon having asked an informal question. Besides, if we're talking about work of writing posts we should also consider the considerable work of reading certain posts, which are so patronizing as to make reading an exercise in eye rolling.
 And thank you for your answer, I always appreciate your answers, but you
 aren't Walter, that post was for him (and Andrei) to answer :-)

FWIW there is little agreement among answers. Eliminating today's semantics of comma inevitably underlies the hope that it can be retrofitted for something else, which I think is near impossible without changing semantics of working code. Then there's a lot of busywork. Eliminating e.g. "with" is going to leave things pretty much where they are with the note some innocently bystanding programs are going to break. One feature to remove stands out - the struct initialization: struct S { int x, y; } S s = { 1, 2 }; This, was noted, makes the order of members effectively part of the struct's interface, which is subtly dangerous. I think we should remove this feature. Andrei
May 01 2012
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/1/12 11:38 PM, Adam D. Ruppe wrote:
 On Wednesday, 2 May 2012 at 03:22:02 UTC, Andrei Alexandrescu wrote:
 One feature to remove stands out - the struct initialization:
 S s = { 1, 2 };

I could live without that one, because D has an alternative: auto s = S(1, 2); And I'd be sad if you took that out, as I use it a lot, especially for trivial types: struct Html { string src; } struct Text { string src; } struct Point { int x; int y; } struct Size { int width; int height; } which I like because then we can use the types for overloading, static checks, etc., and it is very very simple to drop in and use. I guess there could be opCalls or constructors, but poo, it works now without that and I like it.

Well, so probably we shouldn't remove that feature either :o). Andrei
May 02 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/2/12 12:20 AM, Jakob Ovrum wrote:
 S(...) does not exhibit the same problem as {...} exactly because it has
 constructors and static opCall. If you change the order of fields in S,
 you can write a constructor preserving the old behaviour.

Good observation. So indeed the { ... } case is inferior because there's no reasonable way for the library writer to defend against. Andrei
May 02 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/2/12 7:52 AM, bearophile wrote:
 Andrei Alexandrescu:
 FWIW there is little agreement among answers.

Right, but a thread like this is comparable to the first phase of a Brainstorming process, where ideas are produced freely, where agreement is not required.

Sorry, here I meant "agreement" in the statistical sense, i.e. there's not a lot of clear collection of features we should remove; for most features that some wanted to get rid of, others had gainful uses. Andrei
May 02 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 28 Apr 2012 22:40:10 +0200, Artur Skawina <art.08.09 gmail.com>  
wrote:

 On 04/28/12 22:02, Walter Bright wrote:
 On 4/28/2012 12:36 PM, Andrej Mitrovic wrote:
 Also there's mixin templates. What exactly is the difference between
 mixin templates and regular templates?

A mixin template is instantiated in context of the instantiation point, while a regular template is instantiated in the context of the template definition point. This becomes relevant when looking up symbols that are not defined within the template.

Yeah, but this was actually the only suggestion so far in this thread that i could agree with... The issue is template t1() { int a = b; } int main() { int b; mixin t1; return a; } which is currently accepted - and would enforcing the mixin annotation really help anything? artur

At least some of us want mixin templates to be marked mixin at declaration point, and usable without 'mixin': mixin template A( ) { int n; } struct S { A!(); }
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 01:23:17PM +0200, Timon Gehr wrote:
 On 04/29/2012 11:31 AM, foobar wrote:
On Sunday, 29 April 2012 at 08:58:24 UTC, Timon Gehr wrote:


It is not. For example, code that is only executed during CTFE does
never have to behave gracefully if the input is ill-formed.

I disagree - you should make sure the input is valid or all sorts of bad things could potentially happen such as a compiler can get stuck in an infinite loop.

It could fail in a number of other ways. I don't think that this example can be used to invalidate the statement.

Like if the Ackermann function was evaluated in CTFE for very large arguments. Technically it isn't an infinite loop, but you probably wouldn't like the results. T -- If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 04:43:12PM +0200, Jacob Carlborg wrote:
 On 2012-04-28 21:36, Andrej Mitrovic wrote:

Another feature I'm curious about is .dup/.idup. It's basically
hardcoded for a couple of types, but why not instead use UFCS and
implement .dup/.idup in std.array as a free function? Then you might
even use it for user-types by requiring a type to implement
.dup/.idup functions.

Agree with this one as well.

+1. This would make generic code easier to write. Which is good, because the less we have to rewrite code that's been written a hundred times in the past already, the better. T -- A linguistics professor was lecturing to his class one day. "In English," he said, "A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative." A voice from the back of the room piped up, "Yeah, yeah."
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 01:46:25AM -0700, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 10:37:10 Timon Gehr wrote:
 Well, what if the programmer "knows" that foo does not change 'aa',
 but it actually does? Then there would possibly be a segmentation
 fault.  This implies that the 'in' operator cannot be used in  safe
 code. (Or there would have to be a special case, that allows 'in' if
 the result is directly cast to bool.)

It's exactly as safe as any iterator or range which could be invalidated - both of which can occur in safe code. Any of those could blow up in entertaining ways if you use them after they've been invalidated. Pointers are considered safe. It's pointer arithmetic which isn't.

I get that this discussion is about what type 'in' should return, but taking a step back, isn't it all moot because you could just use the .get() method? T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 08:42:23PM +0200, Andrej Mitrovic wrote:
 On 4/29/12, Jacob Carlborg <doob me.com> wrote:
 In principle I agree with you. But in practice this doesn't always
 work.  Take this for example: Prints "0" and "1" as expected. If we
 now change "point" to a property like this: It will now print "0"
 and "0". This is a silently breaking change. Sure you can change
 "point" to return by reference..

This is a great point and an issue I've ran into and talked about before. The compiler really ought to try and convert a call like this: foo.property++; foo.property+=10; into e.g.: foo.property = foo.property.opAdd(1); foo.property = foo.property.opAdd(10); It would make for some really nice APIs if this feature was available.

To me, the compiler needs to be fixed so that anytime the return value of a property is used as an lvalue, it should always try to call the setter function, or some kind of setter function, instead of the getter (unless there's no setter, in which case it's OK to call the getter). I chalk this up to a compiler issue, not a language issue. T -- Let X be the set not defined by this sentence...
Apr 29 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 29, 2012 19:37:50 H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 08:42:23PM +0200, Andrej Mitrovic wrote:
 On 4/29/12, Jacob Carlborg <doob me.com> wrote:
 In principle I agree with you. But in practice this doesn't always
 work.  Take this for example: Prints "0" and "1" as expected. If we
 now change "point" to a property like this: It will now print "0"
 and "0". This is a silently breaking change. Sure you can change
 "point" to return by reference..

This is a great point and an issue I've ran into and talked about before. The compiler really ought to try and convert a call like this: foo.property++; foo.property+=10; into e.g.: foo.property = foo.property.opAdd(1); foo.property = foo.property.opAdd(10); It would make for some really nice APIs if this feature was available.

[...] To me, the compiler needs to be fixed so that anytime the return value of a property is used as an lvalue, it should always try to call the setter function, or some kind of setter function, instead of the getter (unless there's no setter, in which case it's OK to call the getter). I chalk this up to a compiler issue, not a language issue.

Well, it's both really. If the language spec was exact enough, it would say _exactly_ what the correct behavior is here, in which case, either the compiler is currently doing the right thing or it's not, depending on the spec. But the spec isn't that exact, so in some respects, the compiler _is_ the spec. Certainly, the way that this behaves in the language right now is a matter of how the compiler behaves. Ideally though, there would be zero difference between using a property and a public member variable save for taking its address (which should probably just be illegal for property functions). I've been tempted to add an enhancement request for putting property on public member variables to make it so that anything which would would break code if it were switched to a property function wouldn't be legal (such as taking its address). Unfortunately, right now that would include stuff like ++. - Jonathan M Davis
Apr 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-30 04:41, Jonathan M Davis wrote:

 Ideally though, there would be zero difference between using a property and a
 public member variable save for taking its address (which should probably just
 be illegal for  property functions). I've been tempted to add an enhancement
 request for putting  property on public member variables to make it so that
 anything which would would break code if it were switched to a property
 function wouldn't be legal (such as taking its address). Unfortunately, right
 now that would include stuff like ++.

 - Jonathan M Davis

I would rather have property on instance variables be a syntax sugar for implementing property functions. Basically virtual instance variables. -- /Jacob Carlborg
Apr 30 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 09:58, Jacob Carlborg wrote:
 On 2012-04-30 04:41, Jonathan M Davis wrote:

 Ideally though, there would be zero difference between using a
 property and a
 public member variable save for taking its address (which should
 probably just
 be illegal for  property functions). I've been tempted to add an
 enhancement
 request for putting  property on public member variables to make it so
 that
 anything which would would break code if it were switched to a property
 function wouldn't be legal (such as taking its address).
 Unfortunately, right
 now that would include stuff like ++.

 - Jonathan M Davis

I would rather have property on instance variables be a syntax sugar for implementing property functions. Basically virtual instance variables.

Then there better be a way to mark them final too. ;) -- - Alex
Apr 30 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-30 17:27, Alex Rønne Petersen wrote:
 On 30-04-2012 09:58, Jacob Carlborg wrote:

 I would rather have  property on instance variables be a syntax sugar
 for implementing property functions. Basically virtual instance
 variables.

Then there better be a way to mark them final too. ;)

Then what's the point of having a method? Just use a public instance variable. -- /Jacob Carlborg
Apr 30 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 21:43, Jacob Carlborg wrote:
 On 2012-04-30 17:27, Alex Rønne Petersen wrote:
 On 30-04-2012 09:58, Jacob Carlborg wrote:

 I would rather have  property on instance variables be a syntax sugar
 for implementing property functions. Basically virtual instance
 variables.

Then there better be a way to mark them final too. ;)

Then what's the point of having a method? Just use a public instance variable.

Encapsulation. I want contracts in my properties. -- - Alex
Apr 30 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-30 21:56, Alex Rønne Petersen wrote:
 On 30-04-2012 21:43, Jacob Carlborg wrote:
 On 2012-04-30 17:27, Alex Rønne Petersen wrote:
 On 30-04-2012 09:58, Jacob Carlborg wrote:

 I would rather have  property on instance variables be a syntax sugar
 for implementing property functions. Basically virtual instance
 variables.

Then there better be a way to mark them final too. ;)

Then what's the point of having a method? Just use a public instance variable.

Encapsulation. I want contracts in my properties.

Aha, didn't thin of that. Sure, why not. -- /Jacob Carlborg
May 01 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 03:06:53AM +0200, bearophile wrote:
 Jonathan M Davis:
 
* foreach_reverse is essentially redudant at this point (not to
mention
confusing if combined with delegates), since we have retro.

retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...

IMO, the compiler needs to _aggressively_ inline opApply() delegates, unless it's impossible (e.g. opApply is recursive), or perhaps exceeds some reasonable size limit for loop inlining). It's rather disheartening to design a great abstract type for manipulating collections, only to have opApply always incur the overhead of allocating and invoking a delegate _every loop iteration_, even when opApply is as simple as: int opApply(int delegate(ref T arg) dg) { someSetupCode(); for (i=0; i<n; i++) { dg(element[i]); } someCleanupCode(); } As far as I'm concerned, the compiler *should* just inline the whole thing (both opApply and the delegate body) when you write foreach(c; container) {...}. There's no reason for such a trivial loop to incur a call to a delegate every iteration. Powerful abstractions such as opApply need to be optimized to the max, so that D's generic programming capabilities can be a strong selling point. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 10:03:43AM +0400, Dmitry Olshansky wrote:
 On 29.04.2012 5:06, bearophile wrote:

Loops _must_ be fully efficient, they are a basic language construct,
this is very important. Even foreach() is sometimes not equally
efficient as a for() in some cases...

Yesterday I tried GDC. Damn I didn't regret it :)

Unfortunately, even GDC doesn't inline opApply and its delegate for the simplest of loops: struct S { int data[]; int opApply(int delegate(ref int) dg) { foreach (d; data) { if (auto r = dg(d)) return r; } return 0; } } void main() { S s; foreach (e; s) { writeln(e); } } I think it's because the front-end always generates the full delegate passing code without inlining anything. IMO, this case *need* to be aggressively inlined in order to make D's generic programming capabilities a stronger selling point. T -- "Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 02:26:12PM +0200, David Nadlinger wrote:
[...]
  - Comma operator: Kill it with extreme prejudice, it is an
  anti-feature (allow it in for loop expressions if you really want to,
  but I think there are better solutions).

+1. The voice of reason. [...]
  - HexString, DelimitedString, r""-WysiwigString, TokenString: I
 didn't ever use the former two (for including binary data in the
 program, ImportExpression is imho much easier than generating a
 source file containing a HexString).

I found hexstrings useful for writing unittests for testing Unicode handling (I wanted to test both big- and little-endian UTF-16 and UTF-32, whereas currently string literals can only produce native endian). It might also be useful for unittesting code that takes binary input.
 As for r"", every time I actually need WysiwigString, I use backticks,
 because such strings often contain quotes anyway.

+1. I think r"" and `` should be merged. Having both is too much.
 Regarding TokenString(i.e. q{}) – it is certainly a very nice idea,
 especially regarding syntax highlighting, and I occasionally use them
 for CTFE code generation.

I use tokenstrings a lot for mixins. But arguably that use case would be obsolete when D finally finds a good macro system. [...]
  - Concatenation of adjacent strings: Also an anti-feature, imho.

I personally find them useful for nicely-formatting code that contains lots of long strings. But YMMV.
  - Floating point comparison operators like !<>= (yes, that _is_ valid
  D code): I must admit that I seldom write code relying on the finer
  details of IEEE-754 semantics, but can't they just be »lowered« to a
  combination of the more common ones?

Yeah when I was writing a D lexer (just as an exercise) I was flabbergasted at the sheer amount of comparison operators D has. I mean, I don't know if I will ever use *half* of them in my lifetime. After a while my eyes were just glazing over from all the ASCII UFO's that somehow flew into my code from outer space. If IEEE-754 support is what the intention was, I'd recommend putting them in std.math instead of loading the language with a bunch of apparently-oxymoronic operators like !<> and !<>=, that probably nothing outside of IEEE-754 buffs will ever even care about. [...]
  - Built-in arrays and AAs: They are convenient to use, but as far as
  I can see the single biggest GC dependency in the language. Why not
  lower array and AA literals to expression tuples (or whatever) to
  make the convenient syntax usable with custom (possibly non-GC safe)
  containers as well? A GC'd default implementation could then be
  provided in druntime, just like today's arrays and AAs.

AA's are moving into druntime. Yours truly is supposed to make that happen eventually, but lately time hasn't been on my side. :-/ This is an interesting idea, though... once we've fully excised AA's from dmd (aside from convenient lowerings from native syntax), it will open up the possibility of writing a GC-less druntime replacement that also provides an alternate implementation of AA's that don't depend on the GC. T -- This is not a sentence.
Apr 29 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, April 30, 2012 05:12:27 Kapps wrote:
 On Monday, 30 April 2012 at 01:08:28 UTC, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 17:50:48 Don wrote:
 * package. I have no idea how a failed Java experiment got
 incorporated
 into D.

Really? In some cases, it's indispensable. For instance, once std.datetime has been split up, it will require it, or it would have duplicate a bunch of implementation-specific stuff which has no business in the public API. - Jonathan M Davis

It's entirely dependent on your coding style. For example, when you look at Phobos you rarely (if ever?) see package functions. This is because it's entirely module based with a strong degree of separation between modules. However, for someone coming from C#, removing package would be awful. I personally use package quite often. For the most part, I stick to one major class per file, and separate things across library. There are plenty of things that I want other classes in the package/static-library to use, but don't want to expose to the public, and thus use package for.

It's a question of how inter-dependent your modules are (which is partly a question of style). If you have a bunch of closely related functionality that should be in separate modules, then it can be quite easy for it to need have stuff which it needs to share but shouldn't be public. This happens much more easily if you follow a style of putting one class per module as you _must_ do in Java and C# but don't have to do in D. Phobos doesn't have all that many types in it (though that's changing as it grows). Historically, it's been (and mostly still is) a collection of free functions which have been organized in modules with related functions sharing modules. However, free functions tend to be quite independent. At most, they may share some private helpers. They rarely need to share stuff across modules. On top of that, Phobos has historically avoided creating sub-modules in favor of a flat hierarchy (though that's starting to change) The result of this is that package hasn't been needed in Phobos. I suspect that Don's take on things comes from that (and he probably hasn't needed package in his own stuff either). But I don't think that it's very hard at all to come up with examples where package level access can be invaluable. - Jonathan M Davis
Apr 29 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, April 30, 2012 05:20:21 Alex R=C3=B8nne Petersen wrote:
 Except we can't do:
=20
  test
 void myTest()
 {
      // ...
 }
=20
 due to the current lack of annotations and discovery-based reflection=

=20
 *hint hint...*

What would that buy you? That's what unittest blocks are for. Yes, gett= ing=20 custom annotations would be great, and then you could use test for wha= tever=20 you need it for, but unittest blocks are the test functions, so I'm not= quite=20 sure what test would buy you. You _could_ just put a particular string= in a=20 name though (e.g. start all unit test functions with test) and use comp= ile- time reflection to find them if you really want to though (much as that= isn't as=20 nice as a user-defined attribute would be). - Jonathan M Davis
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 04:40:37PM +0200, Jacob Carlborg wrote:
[...]
 * Do-while loops, how useful are those actually?

OK, that got me all riled up about looping constructs, and now I'm provoked to rant: Since the advent of structured programming, looping constructs have always been somewhat b0rken. Yes they worked very well, they are clean, powerful, gets rid of almost all cases of needing goto's, etc.. But the point of a loop is that *the entry point does not always correspond with the exit point (where the loop condition is tested)*. The problem with both do-loops and while-loops is that they are just straitjacketed versions of a more general looping construct. At its most fundamental level, a loop consists of an entry point, a loop body, and some point within the loop body where the loop exits. Sometimes you need multiple exits, but most cases only need a single exit point. So a loop (unrolled) might look like this: codeBeforeLoop(); // Loop body begins here doSomething(); if (!loopCondition) goto exitLoop; doSomethingElse(); doSomething(); if (!loopCondition) goto exitLoop; doSomethingElse(); ... exitLoop: codeAfterLoop(); Note that I deliberately split the loop body into two parts, before the loop condition and after the loop condition. This is because you often have code like this: auto line = nextLine(); while (!eof()) { processLine(line); line = nextLine(); } Notice the duplicated nextLine() call. That's stupid, the initial call to nextLine() is actually already the beginning of the loop. Why do you need to repeat it again inside the loop? Because while-loops always tests the loop condition at the beginning of the loop. OK, what about using a do-loop instead? do { auto line = nextLine(); if (!eof()) processLine(line); } while (!eof()); OK, we got rid of the duplicated nextLine() call, but now we introduced a duplicated eof() test. This is also stupid. The only reason it has to be written in this stupid way is because do-loops always test the loop condition at the end of the loop body, but you need to evaluate the condition BEFORE the second half of the loop body (processLine) is run. But once you've evaluated that condition, the test at the end of the loop body is redundant. So you might say, OK, just write this then: for(;;) { auto line = nextLine(); if (eof()) break; processLine(line); } Well, finally you have something sane. The loop condition now correctly appears in the middle of the loop body, which is where it should've been all along. Only problem is, writing for(;;) is misleading, because you're not looping indefinitely, there's precisely one exit condition. Conveying intent is very important in writing good code, and this code breaks that principle. So really, what is needed is a sane looping construct that unifies while loops, do-loops, and exit-in-the-middle loops. Something like this: loop { // first part of loop body } exitWhen(!loopCondition) { // second part of loop body } It doesn't have to be this exact syntax, but the point is that you need to be able to express loop exits from the middle of a loop body without needing to resort to for(;;) and break, when the loop is a good ole simple loop with a single entry point and a single exit point. (More complex loops that need continue's and break's are, well, more complex, so it's OK to sprinkle if conditions in them like we do now.) </rant> [...]
 * Infix notation for calling any method taking one argument
 * Basically any symbol is allowed in method names
 
 That is:
 
 1 + 2
 foo bar foo_bar
 
 Would be translated to:
 
 1.+(2)
 foo.bar(foo_bar)
 
 That is a very general way to handle operators and let the user
 create new operators, not just overloading existing ones.

While personally, I like the idea of being able to create new infix operators, it will cause too big a change to D syntax, and probably cause lots of breakages with existing code, as well as make the lexer/parser much harder to implement (given the existing D features). You also then have to deal with operator precedence between arbitrary user-defined operators, which is non-trivial in general (though it's workable if you impose some constrains -- but it's probably way beyond the scope of D2 or even D3). T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Apr 29 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Sunday, 29 April 2012 at 20:16:16 UTC, Andrej Mitrovic wrote:
 On 4/29/12, Alex Rønne Petersen <xtzgzorex gmail.com> wrote:
 Next up is the issue of op-assign operations. In D, you can't 
 do:

 obj.foo += 1;
 obj.foo++;

 while in C#, you can (it results in a get -> add 1 -> set and 
 get -> inc
 -> set, etc).

It's great to see another (successful) language implemented this. Do we have a proposal open for this somewhere?

I believe DIP 4 is the proposal http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs But don't forget to check out DIP 5 too.
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 10:26:40PM +0200, Alex Rřnne Petersen wrote:
 On 28-04-2012 22:43, H. S. Teoh wrote:

with statements. They make code hard to read, and besides you can (or
should be able to) alias long expressions into a short identifier for
this purpose anyway.

I don't think I agree entirely here. If you have very long sequences of statements operating on the same object, with can be very useful. That said, I recognize that the current implementation of with needs some work.

I think the correct solution here is to use alias. (If that doesn't work, then it should be made to work. It's a lot cleaner and doesn't introduce potentially nasty ambiguities into code, as well as make code more readable without needing to implement nested symbol tables in your brain.) T -- Help a man when he is in trouble and he will remember you when he is in trouble again.
Apr 29 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, April 30, 2012 06:58:18 David Nadlinger wrote:
 On Monday, 30 April 2012 at 01:08:28 UTC, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 17:50:48 Don wrote:
 * package. I have no idea how a failed Java experiment got
 incorporated
 into D.

Really? In some cases, it's indispensable. For instance, once std.datetime has been split up, it will require it, or it would have duplicate a bunch of implementation-specific stuff which has no business in the public API.

But what happens if std.datetime grows so large that you want to have e.g. a std.datetime.system package, the content of which is accessible from std.datetime.*, but not the rest of the world? =20 This is not an artificial problem, e.g. consider Thrift, where I have e.g. thrift.internal.endian (predating endian stuff in Phobos) which is used from modules in thrift.async, thrift.server, and thrift.protocol, or thrift.internal.socket (containing some more OS abstractions than std.socket does), which is used from modules in thrift.async, thrift.server, and thrift.transport, but both are not part of the public API. =20 The logical =C2=BBpackage=C2=AB to restrict access to would be =C2=BBthrift.*=C2=AB here, but there is no way to restrict access to that, I have to resort to hoping users understand that they should not use =C2=BBthrift.internal.xyz=C2=AB directly. Phobos has t=

 same problem with std.internal.
=20
 I think in Java this problem was the reason for =C2=BBsuper
 packages=C2=AB to be discussed which (I think, haven't followed it
 the developments closely) ended up being incorporated in the
 upcoming Module System feature.

I'm not claiming that package solves all such issues (and you do give s= ome=20 good examples where it would be a problem), but not having it would mak= e the=20 problem even worse. I think that this is one area though where the Wind= ows=20 folks take advantage of their export nonsense and just don't export the= =20 internal stuff. - Jonathan M Davis
Apr 29 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
I don't see export as nonsense. :)

"Jonathan M Davis"  wrote in message 
news:mailman.137.1335762449.24740.digitalmars-d puremagic.com...

On Monday, April 30, 2012 06:58:18 David Nadlinger wrote:
 On Monday, 30 April 2012 at 01:08:28 UTC, Jonathan M Davis wrote:
 On Sunday, April 29, 2012 17:50:48 Don wrote:
 * package. I have no idea how a failed Java experiment got
 incorporated
 into D.

Really? In some cases, it's indispensable. For instance, once std.datetime has been split up, it will require it, or it would have duplicate a bunch of implementation-specific stuff which has no business in the public API.

But what happens if std.datetime grows so large that you want to have e.g. a std.datetime.system package, the content of which is accessible from std.datetime.*, but not the rest of the world? This is not an artificial problem, e.g. consider Thrift, where I have e.g. thrift.internal.endian (predating endian stuff in Phobos) which is used from modules in thrift.async, thrift.server, and thrift.protocol, or thrift.internal.socket (containing some more OS abstractions than std.socket does), which is used from modules in thrift.async, thrift.server, and thrift.transport, but both are not part of the public API. The logical »package« to restrict access to would be »thrift.*« here, but there is no way to restrict access to that, I have to resort to hoping users understand that they should not use »thrift.internal.xyz« directly. Phobos has the same problem with std.internal. I think in Java this problem was the reason for »super packages« to be discussed which (I think, haven't followed it the developments closely) ended up being incorporated in the upcoming Module System feature.

I'm not claiming that package solves all such issues (and you do give some good examples where it would be a problem), but not having it would make the problem even worse. I think that this is one area though where the Windows folks take advantage of their export nonsense and just don't export the internal stuff. - Jonathan M Davis
Apr 30 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 30 April 2012 at 03:16:09 UTC, H. S. Teoh wrote:
 On Sun, Apr 29, 2012 at 02:26:12PM +0200, David Nadlinger wrote:
 […]
  - Built-in arrays and AAs: They are convenient to use, but as 
 far as
  I can see the single biggest GC dependency in the language. 
 Why not
  lower array and AA literals to expression tuples (or 
 whatever) to
  make the convenient syntax usable with custom (possibly 
 non-GC safe)
  containers as well? A GC'd default implementation could then 
 be
  provided in druntime, just like today's arrays and AAs.

AA's are moving into druntime. Yours truly is supposed to make that happen eventually, but lately time hasn't been on my side. :-/

This moves the _implementation_ to druntime, but there is still realistically no way to use AA literals with my own non-GC'd version of hash maps without shipping a custom druntime (and thus modifying the semantics of an existing language construct). What I'm talking about would let you do things like MyVector!int stuff = [1, 2, 3, 4, 5]; without needing a (temporary) GC'd allocation, and thus please the GC-hater crowd because they can still have all the syntax candy with their own containers, even if they can't resp. don't want to use the default GC'd constructs. David
Apr 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 07:07:53AM +0200, David Nadlinger wrote:
 On Monday, 30 April 2012 at 03:16:09 UTC, H. S. Teoh wrote:
On Sun, Apr 29, 2012 at 02:26:12PM +0200, David Nadlinger wrote:
[…]
 - Built-in arrays and AAs: They are convenient to use, but as
far as I can see the single biggest GC dependency in the language.
Why not lower array and AA literals to expression tuples (or
whatever) to make the convenient syntax usable with custom (possibly
non-GC safe) containers as well? A GC'd default implementation could
then be provided in druntime, just like today's arrays and AAs.

AA's are moving into druntime. Yours truly is supposed to make that happen eventually, but lately time hasn't been on my side. :-/

This moves the _implementation_ to druntime, but there is still realistically no way to use AA literals with my own non-GC'd version of hash maps without shipping a custom druntime (and thus modifying the semantics of an existing language construct). What I'm talking about would let you do things like MyVector!int stuff = [1, 2, 3, 4, 5]; without needing a (temporary) GC'd allocation, and thus please the GC-hater crowd because they can still have all the syntax candy with their own containers, even if they can't resp. don't want to use the default GC'd constructs.

I think you're talking about two orthogonal issues here. One is language-level support for arrays and AA's, which IMO are necessary and are even a plus (built-in AA's are one of the big reasons I chose D). The other is language-level support for literal syntax in user-defined types. I think the latter area has lots of room for improvement. From a theoretical standpoint, syntax like [1,2,3,4,5] really should not be prematurely tied to a specific type: at the most fundamental level, it's just specifying a list of things. How the abstract concept of a list of things should be implemented need not be constrained to concrete built-in types; I'd argue that the language should permit the realization of the concept in a user-defined type as well (i.e., the literal interpreted by a user type). Just off the top of my head, this might be achievable by introducing a fromList method in user-defined types that takes a compile-time parameter containing some representation of the list, say as a builtin array. This method then does whatever is needed to create an instance of the type accordingly. (Since the parameter is compile-time, this essentially just generates code to create the custom container directly.) The same thing can be done for custom floating-point literals, say. A fromFloat() method takes a compile-time string containing the literal, and creates an instance of the custom type. (A string is used here so that you can implement types that far exceed the maximum precision of any builtin type.) Ditto for AA literals: a fromAA() method takes a compile-time list of key/value pairs and does whatever it needs to do to create the appropriate runtime AA. In fact, such a construct would alleviate much of the need for compiler hacks to support AA's (both old and the prospective new replacement). There will be no unnecessary overhead of allocating runtime arrays, copying, etc.; the fromAA() method at compile-time generates whatever code is necessary to create the literal into the target object directly. This is a language enhancement issue, though, not really an issue about builtin AA's or arrays being "unnecessary features". T -- All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Apr 29 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/30/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 I think the correct solution here is to use alias. (If that doesn't
 work, then it should be made to work..)

It probably will. Quote Andrei: "Yah, we should add that at some point. Walter and I discussed about it and it's virtually approved. But to be on the conservative side, it's not for expressions but for mere pointer-chasing chains." So this would probably work: alias var.some.deeply.nested.object obj; // use obj here.. I think that's what is being discussed w.r.t. with()?
Apr 29 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, April 30, 2012 07:46:48 Andrej Mitrovic wrote:
 On 4/30/12, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 On Sunday, April 29, 2012 21:56:08 H. S. Teoh wrote:
 I wonder if dmd (or rdmd) should have a mode where it *only* compiles
 unittest code (i.e., no main() -- the resulting exe just runs unittests
 and nothing else).


For RDMD you can do: version(unittest) { } else void main() { // regular code here } And then you can invoke rdmd with --unittest and --main to insert an empty main function when unittesting. Personally I put in a stub main so I don't depend on rdmd features like --main: version(unittest) { void main(string[] args) { } } // stub main else void main() { // regular code here }

Yes, but that still compiles everything. It just gives you a convenient way to have a unit test executable separate from your normal executable. - Jonathan M Davis
Apr 29 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/30/12, Jesse Phillips <jessekphillips+D gmail.com> wrote:
 I believe DIP 4 is the proposal

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

 But don't forget to check out DIP 5 too.

Well it says they're both superseeded by DIP 6 but DIP6 didn't implement things DIP4 was talking about.DIP4 goes on to discuss C#-style properties a bit and acknowledges the issue with += as well. I didn't find anything in bugzilla, so I'm opening an enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=8006
Apr 29 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
 Sorry, I managed to get myself confused here. What I meant to 
 say was that I think >> should do an arithmetic shift if the 
 operands are signed; unsigned shift otherwise.

It does arithmetic shift if the left operand is signed, unsigned shift otherwise. This code: void main() { int a = 0xffffffff; uint b = a; writefln("%x", a >> 1); writefln("%x", b >> 1); } prints ffffffff 7fffffff
Apr 29 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, April 30, 2012 01:41:45 bearophile wrote:
 Walter:
 What's your list?

This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter & Andrei?

Honestly, I don't think that you _can_ take much from this thread other than the fact that pretty _every_ feature is wanted and used by someone, even if other people hate it. Pretty much every feature listed as undesirable by someone was listed as desirable by someone else. As for TODOs, the impression that I got from Walter's post was that he wanted to know what people thought out of curiosity or just for "lessons learned" from the design process of D and not that he was really looking to remove anything from the language. So, I don't think that it was ever his intention to create a TODO list from this (though I could be wrong). There may be some minor things that get changed (such as making it so that adjacent string literals don't get automatically concatenated), but I don't think that D is really going to have any of its features removed at this point. - Jonathan M Davis
Apr 29 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 30-04-2012 20:28, H. S. Teoh wrote:
 On Mon, Apr 30, 2012 at 08:09:31PM +0200, Era Scarecrow wrote:
 On Monday, 30 April 2012 at 17:13:36 UTC, H. S. Teoh wrote:
 It would be unwise to make major changes to the language at this
 point.  Personally I'd like to see the comma operator removed, but
 people keep saying it will break existing code, so that's probably
 not going to happen in D2. D3 perhaps will be able to clean up a lot
 of this mess.

Then perhaps the comma operator can be pushed to the 'depreciated' list for a while; If it breaks anything big and important, you can still compile it. After a while we can see if it should be kept or removed. I think that's the best approach all things considered. Personally, I have yet to really use it outside of a for/foreach statement. On the other hand if it breaks something, generally it will become quite clear where in few the few places and require you to fix and update it before moving on.

Actually it's only inside for. A comma in foreach is not a comma operator but a separator (foreach(a,b;c) is not the same as foreach(b;c)). See, that's another case where it only causes confusion. And I've said many times that inside a for, it really should just be special-cased in for syntax. It should not be an operator in general. T

Indeed. C# just special-cases it inside for. -- - Alex
Apr 30 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/30/2012 10:04 AM, Jonathan M Davis wrote:
 I never claimed that I _was_ Walter. I was pointing out that there's very
 little consensus in this thread (almost all of the comments are in conflict
 with other comments) so that even if it was our intention to go and remove
 things from the language based on this thread, there is very little, if
 anything, that has a clear consensus on being removed. The closest would
 probably be the comma operator, and there wasn't even a complete consensus on
 _that_.

There is less agreement than I thought there would be. This thread also generated far more interest than I anticipated.
 And while I obviously can't say for certain what Walter intended, it was my
 impression that the point of this thread was more out of curiosity and for
 "lessons learned" from designing D than to actually make any changes to the
 language right now (especially when you consider how much Walter hates
 breaking backwards compatibility). But obviously, he'd have to clarify for us
 to know for sure.

The first thing to emphasize is that NONE of this will happen for D2. The emphasis on D2 is fixing implementation and toolchain issues. Breaking existing code is off the table unless we are pretty much forced to in order to fix some other more important issue. So we're talking several years out. The evolution of C++ is interesting. So far, the C++ committee has shown incredible resistance to removing, or even deprecating, some features that pretty much everyone knows were a mistake, all in the interests of maintaining backwards compatibility. Some of C++'s success can be attributed to that, but also some of its endemic failures. Where's the line to draw between breaking existing code and modernizing / removing cruft / removing support for features that promote bad code? Of course, there can't be any fixed rule for that. Hearing peoples' opinions on it on a case by case basis helps a lot. We've had some success in deprecating mistaken features - the bit data type, and typedefs. I'm surprised nobody has mentioned opApply. That was a good idea at the time, but Ranges are a superior solution. I'd like to see new code not use opApply. It's a dead end, though it'll still be supported for a long time.
Apr 30 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 21:50, Walter Bright wrote:
 On 4/30/2012 10:04 AM, Jonathan M Davis wrote:
 I never claimed that I _was_ Walter. I was pointing out that there's very
 little consensus in this thread (almost all of the comments are in
 conflict
 with other comments) so that even if it was our intention to go and
 remove
 things from the language based on this thread, there is very little, if
 anything, that has a clear consensus on being removed. The closest would
 probably be the comma operator, and there wasn't even a complete
 consensus on
 _that_.

There is less agreement than I thought there would be. This thread also generated far more interest than I anticipated.
 And while I obviously can't say for certain what Walter intended, it
 was my
 impression that the point of this thread was more out of curiosity and
 for
 "lessons learned" from designing D than to actually make any changes
 to the
 language right now (especially when you consider how much Walter hates
 breaking backwards compatibility). But obviously, he'd have to clarify
 for us
 to know for sure.

The first thing to emphasize is that NONE of this will happen for D2. The emphasis on D2 is fixing implementation and toolchain issues. Breaking existing code is off the table unless we are pretty much forced to in order to fix some other more important issue. So we're talking several years out. The evolution of C++ is interesting. So far, the C++ committee has shown incredible resistance to removing, or even deprecating, some features that pretty much everyone knows were a mistake, all in the interests of maintaining backwards compatibility. Some of C++'s success can be attributed to that, but also some of its endemic failures. Where's the line to draw between breaking existing code and modernizing / removing cruft / removing support for features that promote bad code? Of course, there can't be any fixed rule for that. Hearing peoples' opinions on it on a case by case basis helps a lot. We've had some success in deprecating mistaken features - the bit data type, and typedefs. I'm surprised nobody has mentioned opApply. That was a good idea at the time, but Ranges are a superior solution. I'd like to see new code not use opApply. It's a dead end, though it'll still be supported for a long time.

I think what we need is an article on ranges on dlang.org (I can't find one). They seem like a rather foreign concept when you come from other languages, like array slices, and need a proper introduction. -- - Alex
Apr 30 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 30-04-2012 22:25, SomeDude wrote:
 On Monday, 30 April 2012 at 19:58:49 UTC, Alex Rønne Petersen wrote:
 On 30-04-2012 21:50, Walter Bright wrote:

 I think what we need is an article on ranges on dlang.org (I can't
 find one). They seem like a rather foreign concept when you come from
 other languages, like array slices, and need a proper introduction.

There is one talk by Andrei http://blip.tv/boostcon/boostcon-2009-keynote-2452140 and there is the chapter on Ali's book: http://ddili.org/ders/d.en/ranges.html

Right, but we can't expect people who want to learn the language and its conventions to have to go to some external source for information. It has to be on dlang.org. -- - Alex
Apr 30 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 09:50 PM, Walter Bright wrote:
 I'm surprised nobody has mentioned opApply. That was a good idea at the
 time, but Ranges are a superior solution. I'd like to see new code not
 use opApply. It's a dead end, though it'll still be supported for a long
 time.

foreach has been mentioned. I don't think ranges are unequivocally a superior solution. opApply is more powerful for fancy iteration tasks, such as parallel foreach.
Apr 30 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/30/2012 1:33 PM, Steven Schveighoffer wrote:
 I think we've already covered this -- opApply does things that ranges could
 never do.

deprecating opApply would require addressing this.
Apr 30 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/30/2012 11:28 PM, bearophile wrote:
 Walter:

 The first thing to emphasize is that NONE of this will happen for D2.
 The emphasis on D2 is fixing implementation and toolchain issues.
 Breaking existing code is off the table unless we are pretty much
 forced to in order to fix some other more important issue.

But you need to keep into account that D2 is still a not widely used language. So deprecating some things now will cause far less troubles than doing it in D3 some years from now.

D2 -> D3 will be full of breaking changes anyway. Otherwise there is no reason to add another major language version.
Apr 30 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/01/2012 12:53 AM, Andrej Mitrovic wrote:
 On 5/1/12, Timon Gehr<timon.gehr gmx.ch>  wrote:
 D2 ->  D3 will be full of breaking changes anyway.

Uhmm I hope not,

Then what is the point of D3?
 otherwise D3 will be dead in the water.

Just provide an automatic D2->D3 conversion facility.
Apr 30 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/01/2012 01:30 AM, Andrej Mitrovic wrote:
 On 5/1/12, Timon Gehr<timon.gehr gmx.ch>  wrote:
 On 05/01/2012 12:53 AM, Andrej Mitrovic wrote:
 On 5/1/12, Timon Gehr<timon.gehr gmx.ch>   wrote:
 D2 ->   D3 will be full of breaking changes anyway.

Uhmm I hope not,

Then what is the point of D3?

An incremental improvement with as little code breakage as possible?

IMHO that is similar to aiming for some code breakage with as little improvement as possible. Retainment of backwards-compatibility is what makes languages convoluted. Furthermore, the translation from D2->D3 should be possible to be performed automatically.
 You can't  even properly mix D1 and D2 code in the same library right now

 without resorting to using mixin() tricks.

This means you actually can!
Apr 30 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, May 01, 2012 01:30:11 Andrej Mitrovic wrote:
 On 5/1/12, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 05/01/2012 12:53 AM, Andrej Mitrovic wrote:
 On 5/1/12, Timon Gehr<timon.gehr gmx.ch> wrote:
 D2 -> D3 will be full of breaking changes anyway.

Uhmm I hope not,

Then what is the point of D3?

An incremental improvement with as little code breakage as possible? You can't even properly mix D1 and D2 code in the same library right now without resorting to using mixin() tricks.

But you could do that without creating a D3. Once the implemnetation has stabilized, it should be possible to add new features to D2 as long as they're backwards compatible (e.g. adding user-defined attributes). The only reason to create D3 would be if we wanted to make changes which _weren't_ backwards compatible. - Jonathan M Davis
Apr 30 2012
prev sibling next sibling parent reply Don Clugston <dac nospam.com> writes:
On 01/05/12 00:33, Timon Gehr wrote:
 On 04/30/2012 11:28 PM, bearophile wrote:
 Walter:

 The first thing to emphasize is that NONE of this will happen for D2.
 The emphasis on D2 is fixing implementation and toolchain issues.
 Breaking existing code is off the table unless we are pretty much
 forced to in order to fix some other more important issue.

But you need to keep into account that D2 is still a not widely used language. So deprecating some things now will cause far less troubles than doing it in D3 some years from now.

D2 -> D3 will be full of breaking changes anyway. Otherwise there is no reason to add another major language version.

What is this D3 thing ???? As far as I can tell, 'D3' was invented by newcomers to the forums.
May 03 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 04-05-2012 01:41, H. S. Teoh wrote:
 On Fri, May 04, 2012 at 01:12:20AM +0200, Era Scarecrow wrote:
 On Thursday, 3 May 2012 at 22:29:47 UTC, H. S. Teoh wrote:
 On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote:
 Do we know (roughly) how many D users are out there right now?

Don't know. Need a poll :) I'm definitely sure we have at least 10 users; beyond that I can only speculate; Maybe 2 to the power of ten or thirteen...

Only 10?? Judging from mailing list membership, I'd say at least 25 or 30, just on the forums alone. I'm assuming that people here aren't subscribed just for kicks, they actually write D code. There are probably more outside the forums (somebody mentioned an entire company of D programmers before, perhaps about 50-100? I don't remember the exact figure). There's got to be more out there, given that Andrei has been giving talks about D for a while. *Somebody* in the audience must be actually listening to what he says. But in any case, I'd say we have a ways to go yet in terms of D adoption.

There are more users than one might think. If you fancy some IRC, you should drop by #d (104 users), #d.gdc (17 users), #ldc (18 users), #d.sdc (5 users) on irc.freenode.net. :) There's also #d on irc.oftc.net (started by Iain).
 [...]
   Anyways, focus on the now. D3 may/will come some day, but that's a
 long ways off. Course if you plan early for certain things that will
 change it does make going towards it easier with language design, or
 give you more time to think about faults and fixes.

Yep. T

-- - Alex
May 03 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-05-03 22:36, Jonathan M Davis wrote:
 On Thursday, May 03, 2012 15:30:40 Don Clugston wrote:
 What is this D3 thing ????
 As far as I can tell, 'D3' was invented by newcomers to the forums.

I think that what it comes down to is that there are a variety of people who want features added or changed in D which are either not going to happen anytime soon or will never happen in D2 (especially if they're major breaking changes). So, they figure/hope that we'll have a new revision of the language where we'll be able to make breaking changes and then maybe the changes that they want will make it in then. After all, particularly from the perspective of a newbie, we already had D2 which changed a bunch of stuff from D1, why wouldn't we have D3 later on? And for folks who really want to see changes that aren't going to happen, the idea that we're going to have another major revision of the language which might make the changes that they want sounds really appealing. I think that Walter and Andrei have made it fairly clear when they've said anything on the subject that there is no intention to make any kind of D3 anytime soon and that if we do, it'll be years from now after D2 is mature and well-established, and it actually makes sense to do a new major revision. But I do think that you're right in that the very idea of a D3 was created by folks in the newsgroup. Walter and the other developers have been focusing on stabilizing D2 as _the_ version of the language, not finishing it up so that they can move onto D3. And the misconceptions about D1 that you've pointed out in the past probably just help contribute to the idea that we'll have a D3 at some point. Maybe we will, maybe we won't, but there's no point in worrying about it for years yet. - Jonathan M Davis

People has been talking about D3 for quite a while. Have a look at: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel Search for "Known to be deferred to D3.0". The features listed there were talked about before D2. -- /Jacob Carlborg
May 04 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 03, 2012 15:30:40 Don Clugston wrote:
 What is this D3 thing ????
 As far as I can tell, 'D3' was invented by newcomers to the forums.

I think that what it comes down to is that there are a variety of people who want features added or changed in D which are either not going to happen anytime soon or will never happen in D2 (especially if they're major breaking changes). So, they figure/hope that we'll have a new revision of the language where we'll be able to make breaking changes and then maybe the changes that they want will make it in then. After all, particularly from the perspective of a newbie, we already had D2 which changed a bunch of stuff from D1, why wouldn't we have D3 later on? And for folks who really want to see changes that aren't going to happen, the idea that we're going to have another major revision of the language which might make the changes that they want sounds really appealing. I think that Walter and Andrei have made it fairly clear when they've said anything on the subject that there is no intention to make any kind of D3 anytime soon and that if we do, it'll be years from now after D2 is mature and well-established, and it actually makes sense to do a new major revision. But I do think that you're right in that the very idea of a D3 was created by folks in the newsgroup. Walter and the other developers have been focusing on stabilizing D2 as _the_ version of the language, not finishing it up so that they can move onto D3. And the misconceptions about D1 that you've pointed out in the past probably just help contribute to the idea that we'll have a D3 at some point. Maybe we will, maybe we won't, but there's no point in worrying about it for years yet. - Jonathan M Davis
May 03 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 3 May 2012 at 20:36:47 UTC, Jonathan M Davis wrote:
 On Thursday, May 03, 2012 15:30:40 Don Clugston wrote:
 What is this D3 thing ????
 As far as I can tell, 'D3' was invented by newcomers to the 
 forums.

I think that what it comes down to is that there are a variety of people who want features added or changed in D which are either not going to happen anytime soon or will never happen in D2 (especially if they're major breaking changes). So, they figure/hope that we'll have a new revision of the language where we'll be able to make breaking changes and then maybe the changes that they want will make it in then. After all, particularly from the perspective of a newbie, we already had D2 which changed a bunch of stuff from D1, why wouldn't we have D3 later on? And for folks who really want to see changes that aren't going to happen, the idea that we're going to have another major revision of the language which might make the changes that they want sounds really appealing. I think that Walter and Andrei have made it fairly clear when they've said anything on the subject that there is no intention to make any kind of D3 anytime soon and that if we do, it'll be years from now after D2 is mature and well-established, and it actually makes sense to do a new major revision. But I do think that you're right in that the very idea of a D3 was created by folks in the newsgroup. Walter and the other developers have been focusing on stabilizing D2 as _the_ version of the language, not finishing it up so that they can move onto D3. And the misconceptions about D1 that you've pointed out in the past probably just help contribute to the idea that we'll have a D3 at some point. Maybe we will, maybe we won't, but there's no point in worrying about it for years yet.

If anything, I would consider D3 an ideal, something to work towards. And no it wouldn't be started or really worked on for at 10-15 years after D's mature and at Andrei's goal of having at least a million users. And as stated before, if there [b]IS[/b] going to be a D3 at any point it should have no problem calling D2 code. Course thinking of D3 now is kinda like thinking of flying cars and how you want a flying car and you won't buy a car today until it can fly... Back (in the 50-60's was it?) they thought we would be having a flying car for every family and had these really badly done animations of what they expected to see. I don't see any flying cars outside of Hollywood. Best if we stick in the present and deal with our problems now.
May 03 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote:
[[...]
  If anything, I would consider D3 an ideal, something to work
 towards. And no it wouldn't be started or really worked on for at
 10-15 years after D's mature and at Andrei's goal of having at least
 a million users. And as stated before, if there [b]IS[/b] going to
 be a D3 at any point it should have no problem calling D2 code.

Do we know (roughly) how many D users are out there right now?
  Course thinking of D3 now is kinda like thinking of flying cars and
 how you want a flying car and you won't buy a car today until it can
 fly...  Back (in the 50-60's was it?) they thought we would be
 having a flying car for every family and had these really badly done
 animations of what they expected to see. I don't see any flying cars
 outside of Hollywood. Best if we stick in the present and deal with
 our problems now.

There aren't any flying cars in Hollywood either. They're either just artist's concepts (*cough*CGI models*cough*), held up by strings, or just superimposed on an animated background. T -- It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford
May 03 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 3 May 2012 at 22:29:47 UTC, H. S. Teoh wrote:
 On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote:
 Do we know (roughly) how many D users are out there right now?

Don't know. Need a poll :) I'm definitely sure we have at least 10 users; beyond that I can only speculate; Maybe 2 to the power of ten or thirteen...
 There aren't any flying cars in Hollywood either. They're 
 either just artist's concepts (*cough*CGI models*cough*), held 
 up by strings, or just superimposed on an animated background.

Exactly! It's on the 'big screen', meaning smoke and gimmicks, the same as magicians. Anyways, focus on the now. D3 may/will come some day, but that's a long ways off. Course if you plan early for certain things that will change it does make going towards it easier with language design, or give you more time to think about faults and fixes.
May 03 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 04, 2012 at 01:12:20AM +0200, Era Scarecrow wrote:
 On Thursday, 3 May 2012 at 22:29:47 UTC, H. S. Teoh wrote:
On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote:
Do we know (roughly) how many D users are out there right now?

Don't know. Need a poll :) I'm definitely sure we have at least 10 users; beyond that I can only speculate; Maybe 2 to the power of ten or thirteen...

Only 10?? Judging from mailing list membership, I'd say at least 25 or 30, just on the forums alone. I'm assuming that people here aren't subscribed just for kicks, they actually write D code. There are probably more outside the forums (somebody mentioned an entire company of D programmers before, perhaps about 50-100? I don't remember the exact figure). There's got to be more out there, given that Andrei has been giving talks about D for a while. *Somebody* in the audience must be actually listening to what he says. But in any case, I'd say we have a ways to go yet in terms of D adoption. [...]
  Anyways, focus on the now. D3 may/will come some day, but that's a
 long ways off. Course if you plan early for certain things that will
 change it does make going towards it easier with language design, or
 give you more time to think about faults and fixes.

Yep. T -- Those who don't understand Unix are condemned to reinvent it, poorly.
May 03 2012
prev sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 3 May 2012 at 23:40:32 UTC, H. S. Teoh wrote:
 Only 10?? Judging from mailing list membership, I'd say at 
 least 25 or 30, just on the forums alone. I'm assuming that 
 people here aren't subscribed just for kicks, they actually 
 write D code. There are probably more outside the forums 
 (somebody mentioned an entire company of D programmers before, 
 perhaps about 50-100? I don't remember the exact figure). 
 There's got to be more out there, given that Andrei has been 
 giving talks about D for a while. *Somebody* in the audience 
 must be actually listening to what he says.

I was being sarcastic :P
May 03 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/01/2012 12:54 AM, Kapps wrote:
 On Monday, 30 April 2012 at 19:50:36 UTC, Walter Bright wrote:
 I'm surprised nobody has mentioned opApply. That was a good idea at
 the time, but Ranges are a superior solution. I'd like to see new code
 not use opApply. It's a dead end, though it'll still be supported for
 a long time.

I practically never use ranges, and instead use opApply for all my code. 1) Ranges force me to use a specific naming convention. My naming convention that I use for my projects is upper camel case. Ranges do not allow this.

Yes they do. (If you are willing to have both kinds of symbols around.) mixin template AddAliasesForBuiltInRange(){ alias Front front; alias Empty empty; alias PopFront popFront; } struct R{ ... property Front(){...} property bool Empty(){...} void PopFront(){...} mixin AddAliasesForBuiltInRange; }
 Technically opApply is still lower camel case, but my code
 doesn't directly call it.

The same would hold for the above example.
 2) Ranges don't have a way of determining when the iteration ends.
 Sometimes you want to do something once iteration stops. For example, by
 far the most common action when executing a database call for me, is to
 iterate over it and close it. I can then have a helper method that
 executes the command and closes it when the foreach is done (whether by
 break or by the function ending). This saves quite a bit of boiler plate
 code.

An important point.
 3) Ranges can be difficult to implement. You now have to keep track of
 state instead of simply leaving everything inside a single method call.
 This can also cause significant problems with multi-threaded code.

 4) Ranges take a lot more code, which when all you want is basic
 iteration, is pointless to have

Those two could be mitigated by moving the range concept further into the language.
 I'd much rather just see things with opApply being able to have a
 forward-range magically created for it, much like the reverse. Not sure
 if this is possible or practical though.

Am implementation (that is possible now) could use coroutines (core.thread.Fiber), but that is not very efficient for simple iteration. Compiler support would be a solution. See eg. C# yield return. (In D the compiler would generate anonymous struct types instead of IEnumerable interface implementations).
Apr 30 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/01/2012 01:20 AM, akaz wrote:
 I expected to meet D and exclaim: wow! C++ done right! Instead, I feel
 like being forced to learn another,

Yes, D is its own thing.
 completely new paradigm language,
 like I would start with Lisp or something else.

OTOH, this seems to be an exaggeration.
 Remember:
 "Within D, there is a much smaller and cleaner language struggling to
 get out".

I don't see the value of that assertion from a pragmatic point of view. What is to be gained? Note that you have discussed mostly syntax. * adding -> does not make the language smaller or cleaner and it complicates generic code for no benefit. * loosening the syntactic distinction between value and reference type variable declarations could be done, (to the neat effect that tail-qualified class references would trivially work) but there shouldn't be any directly built-in support for treating polymorphic class instances as values. * I agree that the property situation needs to be cleaned up. There are only five annotations in total. And what you have said does not apply to the other four. * how p[0..len] can be seen as an issue instead of as great completely escapes my mind. * I agree on supporting deducing length for static arrays. (there is a int[$] arr = [1,2,3]; proposal.) * the syntax for arrays is straightforward and I don't see any potential for improvement. * the foo(a,&b) example is biased because it uses a meaningless function name. From the function name alone it is often *almost* clear that a certain argument will be modified. & & & spam is not 'clean' either.
Apr 30 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 02:14, bearophile wrote:
 Timon Gehr:

 * I agree on supporting deducing length for static arrays. (there is a
 int[$] arr = [1,2,3]; proposal.)

Someone in Bugzilla ha just proposed an alternative idea, that despite not looking very nice, is not overall bad (here with a small change): auto arr = [1, 2, 3]f; That trailing f denotes a fixed-side array/string literal. So it's usable for other situations too.
 * the foo(a,&b) example is biased because it uses a meaningless
 function name. From the function name alone it is often *almost*
 clear that a certain argument will be modified. & & & spam is not
 'clean' either.

In C# you need to use "ref" and "out" at the calling point (in most cases). D language has chosen a different design, but here C# design has some advantages too, it makes the code semantics a bit more clear.

Tell me about it... I've had a few WTF and WAT moments due to D's design here.
 Bye,
 bearophile

-- - Alex
Apr 30 2012
prev sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 05/01/12 02:25, H. S. Teoh wrote:
 On Tue, May 01, 2012 at 02:14:42AM +0200, bearophile wrote:
 Timon Gehr:

 * I agree on supporting deducing length for static arrays. (there
 is a
  int[$] arr = [1,2,3]; proposal.)

Someone in Bugzilla ha just proposed an alternative idea, that despite not looking very nice, is not overall bad (here with a small change): auto arr = [1, 2, 3]f; That trailing f denotes a fixed-side array/string literal. So it's usable for other situations too.

I don't like it. An f prefix already means float in another context; overloading it to also mean static array is a bad idea. D already has too much overloaded syntax (like static meaning all sorts of diverse things depending on context). I much prefer the int[$] proposal, because $ already means "length of array" in D, and so would fit right in.

Since one of the most characteristic D features is overloading "static" whenever possible, this would fit right in: auto arr = static [1, 2, 3]; artur
May 01 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-01 11:50, Artur Skawina wrote:

 Since one of the most characteristic D features is overloading "static"
 whenever possible, this would fit right in:

     auto arr = static [1, 2, 3];

 artur

Meaning this would need to be allowed: static arr = static [1, 2, 3]; That looks a bit confusing. -- /Jacob Carlborg
May 01 2012
prev sibling next sibling parent simendsjo <simendsjo gmail.com> writes:
On Mon, 30 Apr 2012 09:24:44 +0200, Jacob Carlborg <doob me.com> wrote:

 On 2012-04-30 00:07, Manu wrote:
 On 29 April 2012 23:00, Alex R=C3=B8nne Petersen <xtzgzorex gmail.com=


 <mailto:xtzgzorex gmail.com>> wrote:

     Let's get a standard package manager that we either advocate on
     dlang.org <http://dlang.org> or include in the releases before we=


     start talking about reducing the amount of modules in Phobos.


 Oh hell yes! I have exciting dreams of something like this every othe=


 night ;)

I'm working on this. Unfortunately I cannot work on this full-time so =

 basically nothing gets done.

 https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for=

 https://github.com/jacob-carlborg/orbit

Vibe.d has its own: = https://github.com/rejectedsoftware/vibe.d/tree/master/source/vibe/vpm And we have dsss: https://github.com/apriori/dsss And it seems this might be related too: = https://github.com/dbuilder-developers/dbuilder Getting orbit up and running would have been great.
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 I think the correct solution here is to use alias. (If that 
 doesn't
 work, then it should be made to work. It's a lot cleaner and 
 doesn't
 introduce potentially nasty ambiguities into code,

What ambiguities? Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Honestly, I don't think that you _can_ take much from this 
 thread other than

I don't agree, I see some recurring patterns. People have spent energy and time to write lot of answers in this thread, some good answer bits too, so I expect such work to not let be fully wasted. Asking for opinions, receiving lot of them, and then ignoring them all is not a good way to run a community. And thank you for your answer, I always appreciate your answers, but you aren't Walter, that post was for him (and Andrei) to answer :-) Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 07:37:13 UTC, Dmitry Olshansky wrote:

Right, nowdays any compiler is either smart enough or a dead meat that nobody uses. P.S. dmd is kind of work in progress ;)

A smart enough compiler would understand natural language and turn it into efficient assembly. :o)
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 07:52:10 UTC, Dmitry Olshansky wrote:
 On 30.04.2012 10:55, Jonathan M Davis wrote:
 On Monday, April 30, 2012 01:41:45 bearophile wrote:
 Walter:
 What's your list?

This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter& Andrei?

Honestly, I don't think that you _can_ take much from this thread other than the fact that pretty _every_ feature is wanted and used by someone, even if other people hate it. Pretty much every feature listed as undesirable by someone was listed as desirable by someone else.

foreach_reverse, comma operator, etc.

These are the only two I can count that nobody felt eager to keep. Yet these are only nitpicks. Also, both work, so the benefit of removing them vs breaking code... I would be glad to remove the current comma operator if its semantic was changed for something like this: http://forum.dlang.org/post/ajdmseliewbindkkoxxj forum.dlang.org But I don't think it's on the table. So I believe the conclusion several of us have reached is, that it's more important to make things that already exist work as intended without ugly corner cases and hacks.
Apr 30 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
Meta comment: C++ is the spawn of the devil so I don't accept 
anything related to c++ as a valid argument.

On Sunday, 29 April 2012 at 20:09:34 UTC, Alex Rønne Petersen 
wrote:
[...]
 I have used D and didn't claim that foreach isn't useful.
 What I said that is that it belongs in the library, NOT the 
 language.

Yeah, we tried that in C++. It sucked.

See meta comment above.
 The reason it works for many functional languages is that they 
 have even more terse syntax than D. It would suck to make 
 foreach a function in D.

D wants to support functional programming. That means we should provide whatever is necessary to write functional style code including foreach methods. IF D can't properly implement a FP foreach method (And IMO it *can*) than we have failed.
 * version - this does not belong in a programming language. 
 Git
 is a much better solution.

So you'd maintain a git branch for every OS if there is some small part that is OS-dependent? I don't think that is a better approach at all.

It is far better than having a pile of #ifdef styled spaghetti code. I'd expect to have all the OS specific code encapsulated separately anyway, not spread around the code base. Which is the current recommended way of using versions anyway. The inevitable conclusion would be to either use a version management system like git or have separate implementation modules for platform specific code and use the build tool to implement the logic of select the modules to include in the build.

Yeah, we tried that in C and C++. It sucked. See: Autotools.

see meta comment above. The fact that you used a horribly designed language with a horrible mess of a "build tool" made out of shell scripts IIRC is not an indication that the language should include build-tool functionality.
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 11:46:09AM +0400, Dmitry Olshansky wrote:
 On 30.04.2012 9:33, H. S. Teoh wrote:

I think the latter area has lots of room for improvement. From a
theoretical standpoint, syntax like [1,2,3,4,5] really should not be
prematurely tied to a specific type: at the most fundamental level,
it's just specifying a list of things. How the abstract concept of a
list of things should be implemented need not be constrained to
concrete built-in types; I'd argue that the language should permit
the realization of the concept in a user-defined type as well (i.e.,
the literal interpreted by a user type).

Just off the top of my head, this might be achievable by introducing
a fromList method in user-defined types that takes a compile-time
parameter containing some representation of the list, say as a
builtin array. This method then does whatever is needed to create an
instance of the type accordingly. (Since the parameter is
compile-time, this essentially just generates code to create the
custom container directly.)


 *cough* initializer lists *cough*
 
 Seriously let AA liters be an sorted initializer list (conceptual
 compile-time array) of pairs, and normal array literal just plain
 initializer list of common type.
 
 This also nails nicely strange use case of AA literal to build array
 (just the same sorted table of pairs!).  The AA then is just
 initialized with sorted array at run-time. (as it does anyway)

+1, this is an excellent idea! It also solves the case of byte[], uint[], int[], etc., all being initializable by "[1,2,3]". Currently, subtle bugs are introduced in certain contexts by the compiler interpreting [1,2,3] to be int[] by default. What we really should do is to pass it in as a compile-time initializer list to the relevant ctors. So byte[].this() will interpret [1,2,3] as bytes, uint[].this() will interpret it as uints, etc.. Then you can write: uint[] a = [ 2: 100, 10: 200 ] and it will be equivalent to: uint[] a = [0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 200]; T -- The most powerful one-line C program: #include "/dev/tty" -- IOCCC
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 10:21:23AM +0200, bearophile wrote:
 H. S. Teoh:
 
I think the correct solution here is to use alias. (If that doesn't
work, then it should be made to work. It's a lot cleaner and doesn't
introduce potentially nasty ambiguities into code,

What ambiguities?

When you have nested with's. Or when the object members shadow local variables in the parent scope. struct S { int x; } void main() { int x, y; S s; with(s) { x = 1; y = 2; } } Technically it's unambiguous which symbols are being referred to, but it makes the code hard to read because casual scanning will usually get it wrong. Plus, you're entirely at the mercy of the definition of S. If it's an imported object from an external library, for example, then when upstream makes changes to their struct/class there's a risk of introducing subtle errors into existing, correct code (by suddenly interpreting an identifier differently). This is never good. It gets worse with nested with's: when any object being with'd changes, you risk identifier collision. The worst thing is that this can happen just by upstream(s) changing object definitions, with no change in user code. T -- Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Apr 29, 2012 at 11:55:43PM -0700, Jonathan M Davis wrote:
[...]
 Honestly, I don't think that you _can_ take much from this thread
 other than the fact that pretty _every_ feature is wanted and used by
 someone, even if other people hate it. Pretty much every feature
 listed as undesirable by someone was listed as desirable by someone
 else.

So far, I've not seen a single response in favor of keeping the comma operator. T -- Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 05:26:15PM +0200, Alex Rřnne Petersen wrote:
 On 30-04-2012 01:41, bearophile wrote:
Walter:

What's your list?

This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter & Andrei?


 I think the one thing there is universal agreement on is that the
 comma operator has to go.

+1. Let's rid the comma operator of its miserable existence. T -- Computers aren't intelligent; they only think they are.
Apr 30 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 30 April 2012 at 15:35:19 UTC, H. S. Teoh wrote:
 So far, I've not seen a single response in favor of keeping the 
 comma operator.

I kinda like having it....
Apr 30 2012
prev sibling next sibling parent simendsjo <simendsjo gmail.com> writes:
On Mon, 30 Apr 2012 17:35:14 +0200, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:

 On Mon, Apr 30, 2012 at 10:21:23AM +0200, bearophile wrote:
 H. S. Teoh:

I think the correct solution here is to use alias. (If that doesn't
work, then it should be made to work. It's a lot cleaner and doesn't
introduce potentially nasty ambiguities into code,

What ambiguities?

When you have nested with's. Or when the object members shadow local variables in the parent scope. struct S { int x; } void main() { int x, y; S s; with(s) { x = 1; y = 2; } } Technically it's unambiguous which symbols are being referred to, but it makes the code hard to read because casual scanning will usually get it wrong. Plus, you're entirely at the mercy of the definition of S. If it's an imported object from an external library, for example, then when upstream makes changes to their struct/class there's a risk of introducing subtle errors into existing, correct code (by suddenly interpreting an identifier differently). This is never good. It gets worse with nested with's: when any object being with'd changes, you risk identifier collision. The worst thing is that this can happen just by upstream(s) changing object definitions, with no change in user code. T

I think struct literals is worse in this regard: struct S { int a; int b; } user code: S(1, 2); The author of S cleans up the struct and changes the order: struct S { int b; int a; } Suddely user code has bugs. I believe the reason named parameters hasn't been introduced is because the names becomes part of the public interface. Well.. With struct literals, the _position_ of the parameters is part of the interface.
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 When you have nested with's.

 Or when the object members shadow local variables in the parent 
 scope.

 	struct S {
 		int x;
 	}

 	void main() {
 		int x, y;
 		S s;

 		with(s) {
 			x = 1;
 			y = 2;
 		}
 	}

That code doesn't compile: test.d(10): Error: with symbol test.S.x is shadowing local symbol test.main.x Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Monday, 30 April 2012 at 15:38:32 UTC, Adam D. Ruppe wrote:
 On Monday, 30 April 2012 at 15:35:19 UTC, H. S. Teoh wrote:
 So far, I've not seen a single response in favor of keeping 
 the comma operator.

I kinda like having it....

I too and I am afraid that disallowing it would result that something would be broken.
Apr 30 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 30 April 2012 at 15:35:19 UTC, H. S. Teoh wrote:
 So far, I've not seen a single response in favor of keeping the 
 comma
 operator.

Very few want it, but as a practicality, it would be unwise to remove it (would break an awful lot of code).
Apr 30 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 30 April 2012 at 15:38:41 UTC, simendsjo wrote:
 I think struct literals is worse in this regard:
 struct S {
   int a;
   int b;
 }

 user code:
 S(1, 2);

 The author of S cleans up the struct and changes the order:
 struct S {
   int b;
   int a;
 }

 Suddely user code has bugs. I believe the reason named 
 parameters hasn't been introduced is because the names becomes 
 part of the public interface. Well.. With struct literals, the 
 _position_ of the parameters is part of the interface.

Structs provide POD value types and as such MUST include the position as part of the interface. The memory layout of these types is used to copy, compare, transmit over the net, etc. If you want encapsulation you need to at the least to define a ctor or maybe change to a class. I'd be very upset if I defined a struct for serialization/transmitting over the net/etc and changing its memory _didn't_ cause loud compiler errors. named parameters are 99% of the time a horrible idea and likely indicate a design flaw.
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 05:47:59PM +0200, bearophile wrote:
 H. S. Teoh:
 
When you have nested with's.

Or when the object members shadow local variables in the parent
scope.

	struct S {
		int x;
	}

	void main() {
		int x, y;
		S s;

		with(s) {
			x = 1;
			y = 2;
		}
	}

That code doesn't compile: test.d(10): Error: with symbol test.S.x is shadowing local symbol test.main.x

Which means your code is at the mercy of the external library. Upstream updates a class, and suddenly a whole bunch of code is unnecessarily broken (if you had just used aliases instead, there would be no problem). T -- It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 Which means your code is at the mercy of the external library.
 Upstream updates a class, and suddenly a whole bunch of code is
 unnecessarily broken

How? (I think you are wrong again). Bye, bearohile
Apr 30 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, April 30, 2012 11:15:17 bearophile wrote:
 Jonathan M Davis:
 Honestly, I don't think that you _can_ take much from this
 thread other than

I don't agree, I see some recurring patterns. People have spent energy and time to write lot of answers in this thread, some good answer bits too, so I expect such work to not let be fully wasted. Asking for opinions, receiving lot of them, and then ignoring them all is not a good way to run a community. And thank you for your answer, I always appreciate your answers, but you aren't Walter, that post was for him (and Andrei) to answer :-)

I never claimed that I _was_ Walter. I was pointing out that there's very little consensus in this thread (almost all of the comments are in conflict with other comments) so that even if it was our intention to go and remove things from the language based on this thread, there is very little, if anything, that has a clear consensus on being removed. The closest would probably be the comma operator, and there wasn't even a complete consensus on _that_. And while I obviously can't say for certain what Walter intended, it was my impression that the point of this thread was more out of curiosity and for "lessons learned" from designing D than to actually make any changes to the language right now (especially when you consider how much Walter hates breaking backwards compatibility). But obviously, he'd have to clarify for us to know for sure. - Jonathan M Davis
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 06:54:31PM +0200, bearophile wrote:
 H. S. Teoh:
 
Which means your code is at the mercy of the external library.
Upstream updates a class, and suddenly a whole bunch of code is
unnecessarily broken

How? (I think you are wrong again).

struct S { int x; } void main() { int y; S s; with(s) { x = 1; y = 2; } } This works. Now suppose S is updated to: struct S { int x; int y; } Now the program fails to compile because S.y conflicts with the local y. This is bad because unrelated code is broken just by changing S: it breaks encapsulation. This is just a small example; imagine if a lot of code uses S. Many places may break when S changes just because they happen to use the wrong local variable names. Whereas if you had _not_ used with, this is a non-problem, since you'd be referring to s.x, and the fact that S now has a new member does not break any existing code regardless of how it was named. T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 This is bad because unrelated code is broken just by changing 
 S: it
 breaks encapsulation. This is just a small example; imagine if 
 a lot of
 code uses S. Many places may break when S changes just because 
 they
 happen to use the wrong local variable names.

But it's a kind of safe breaking, it doesn't cause a lot of silent bugs. I have found with useful in many situation to reduce the noise in my code. Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 01:04:01PM -0400, Jonathan M Davis wrote:
[...]
 And while I obviously can't say for certain what Walter intended, it
 was my impression that the point of this thread was more out of
 curiosity and for "lessons learned" from designing D than to actually
 make any changes to the language right now (especially when you
 consider how much Walter hates breaking backwards compatibility). But
 obviously, he'd have to clarify for us to know for sure.

It would be unwise to make major changes to the language at this point. Personally I'd like to see the comma operator removed, but people keep saying it will break existing code, so that's probably not going to happen in D2. D3 perhaps will be able to clean up a lot of this mess. And frankly, most of the responses on this thread (including my own, I'll admit) are more wishlist items than the truly "redundant" features that Walter referred to initially. And I have to say that in spite of little annoyances here and there, D2 is still the closest to my ideal programming language, and that's unlikely to change anytime soon. What we really need to focus on now is to hone the existing features, clean up the bugs, and improve the implementation, rather than continue to introduce new features and breaking changes. Existing features really need to Just Work(tm). We will drive away many potential D users by incomplete/buggy implementation of advertised features. T -- There are three kinds of people in the world: those who can count, and those who can't.
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
foobar:

 named parameters are 99% of the time a horrible idea and likely 
 indicate a design flaw.

Named arguments help avoid some bugs, make the code more readable, and having used them for many years, they don't seem to indicate significant flaws in my code. Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 30 April 2012 at 17:13:36 UTC, H. S. Teoh wrote:
 On Mon, Apr 30, 2012 at 01:04:01PM -0400, Jonathan M Davis It 
 would be unwise to make major changes to the language at this 
 point.
 Personally I'd like to see the comma operator removed, but 
 people keep
 saying it will break existing code, so that's probably not 
 going to
 happen in D2. D3 perhaps will be able to clean up a lot of this 
 mess.

Then perhaps the comma operator can be pushed to the 'depreciated' list for a while; If it breaks anything big and important, you can still compile it. After a while we can see if it should be kept or removed. I think that's the best approach all things considered. Personally, I have yet to really use it outside of a for/foreach statement. On the other hand if it breaks something, generally it will become quite clear where in few the few places and require you to fix and update it before moving on.
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 08:09:31PM +0200, Era Scarecrow wrote:
 On Monday, 30 April 2012 at 17:13:36 UTC, H. S. Teoh wrote:
It would be unwise to make major changes to the language at this
point.  Personally I'd like to see the comma operator removed, but
people keep saying it will break existing code, so that's probably
not going to happen in D2. D3 perhaps will be able to clean up a lot
of this mess.

Then perhaps the comma operator can be pushed to the 'depreciated' list for a while; If it breaks anything big and important, you can still compile it. After a while we can see if it should be kept or removed. I think that's the best approach all things considered. Personally, I have yet to really use it outside of a for/foreach statement. On the other hand if it breaks something, generally it will become quite clear where in few the few places and require you to fix and update it before moving on.

Actually it's only inside for. A comma in foreach is not a comma operator but a separator (foreach(a,b;c) is not the same as foreach(b;c)). See, that's another case where it only causes confusion. And I've said many times that inside a for, it really should just be special-cased in for syntax. It should not be an operator in general. T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.
Apr 30 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/30/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 Then
 you can write:

 	uint[] a = [
 		2: 100,
 		10: 200
 	]

 and it will be equivalent to:

 	uint[] a = [0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 200];

But you can already use this syntax right now?
Apr 30 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 30 April 2012 at 18:46:02 UTC, Timon Gehr wrote:
 On 04/30/2012 05:36 PM, H. S. Teoh wrote:
 So far, I've not seen a single response in favor of keeping 
 the comma
 operator.

think it should be removed for the sake of removing it. If it is removed, the syntax should be reused.

Care to show some examples? David
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 09:06:06PM +0200, Andrej Mitrovic wrote:
 On 4/30/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 Then
 you can write:

 	uint[] a = [
 		2: 100,
 		10: 200
 	]

 and it will be equivalent to:

 	uint[] a = [0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 200];

But you can already use this syntax right now?

Yes I know you can, it was more of using this syntax for user-defined types without allocating a temporary array. T -- Computers shouldn't beep through the keyhole.
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 30, 2012 at 08:46:02PM +0200, Timon Gehr wrote:
 On 04/30/2012 05:36 PM, H. S. Teoh wrote:

So far, I've not seen a single response in favor of keeping the comma
operator.


 I think I use it about every 60 lines of code. Also, I don't think it
 should be removed for the sake of removing it. If it is removed, the
 syntax should be reused.

We already have a reuse waiting in the line up, for a looong time. Native tuple syntax. T -- Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye
Apr 30 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/28/2012 11:47 AM, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The idea was
 which features in D are redundant and/or do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble and creal
 types.

 What's your list?

This certainly seems to have become the biggest thread ever!
Apr 30 2012
next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
On 5/1/12 2:24 AM, Walter Bright wrote:
 On 4/28/2012 11:47 AM, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this question. The
 idea was
 which features in D are redundant and/or do not add significant value?

 A couple already agreed upon ones are typedef and the cfloat, cdouble
 and creal
 types.

 What's your list?

This certainly seems to have become the biggest thread ever!

Apr 30 2012
prev sibling next sibling parent "Eyyub" <eyyub.pangearaion gmail.com> writes:
On Monday, 30 April 2012 at 19:24:50 UTC, Walter Bright wrote:
 On 4/28/2012 11:47 AM, Walter Bright wrote:
 Andrei and I had a fun discussion last night about this 
 question. The idea was
 which features in D are redundant and/or do not add 
 significant value?

 A couple already agreed upon ones are typedef and the cfloat, 
 cdouble and creal
 types.

 What's your list?

This certainly seems to have become the biggest thread ever!

Yes, this is a very interesting discussion, even for a n00b like me ! (and even if i didn't understand everything)
Apr 30 2012
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 19:24:50 UTC, Walter Bright wrote:
 This certainly seems to have become the biggest thread ever!

What did you expect, really ? That people would say "nothing, the language is perfect" ? :D When I saw your question, I immediately thought "damn, Walter is starting a troll thread for fun, it's gonna be a huge waste of time". :D But then I changed my mind, because what I saw, - and that's what I expected actually -, is that almost everybody had a different list from other people. Which is in fact good, because that means that everybody uses his own subset of the language for his own use, and although there is a common ground, the union of all subsets seems to pretty much fill the "design space" of the language. In the end, very few "features" seem to be universally disdained (the comma operator seems to come regularly, though, but even that one has supporters). Which means to me that in terms of overall design, the language is not in a bad shape at all. So the design phase seems almost complete. The real effort now must be to finish the implementation, and build a full productive ecosystem. And I suppose we are still far from that goal.
Apr 30 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 30/04/2012 22:52, SomeDude a Ă©crit :
 In the end, very few "features" seem to be universally disdained (the
 comma operator seems to come regularly, though, but even that one has
 supporters). Which means to me that in terms of overall design, the
 language is not in a bad shape at all.

I wouldn't say supporter, but some people think it doesn't worth the cost of breaking code. BTW, you'll find lazy too.
Apr 30 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/01/2012 12:12 AM, deadalnix wrote:
 Le 30/04/2012 22:52, SomeDude a Ă©crit :
 In the end, very few "features" seem to be universally disdained (the
 comma operator seems to come regularly, though, but even that one has
 supporters). Which means to me that in terms of overall design, the
 language is not in a bad shape at all.

I wouldn't say supporter, but some people think it doesn't worth the cost of breaking code. BTW, you'll find lazy too.

call by name is useful.
Apr 30 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 30 April 2012 at 19:50:36 UTC, Walter Bright wrote:
 I'm surprised nobody has mentioned opApply.

opApply is great. I find myself finding new, kinda crazy things to do with it every so often, like concurrency sugar.
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 19:58:49 UTC, Alex Rønne Petersen 
wrote:
 On 30-04-2012 21:50, Walter Bright wrote:

 I think what we need is an article on ranges on dlang.org (I 
 can't find one). They seem like a rather foreign concept when 
 you come from other languages, like array slices, and need a 
 proper introduction.

There is one talk by Andrei http://blip.tv/boostcon/boostcon-2009-keynote-2452140 and there is the chapter on Ali's book: http://ddili.org/ders/d.en/ranges.html
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 20:04:41 UTC, Timon Gehr wrote:
 On 04/30/2012 09:50 PM, Walter Bright wrote:
 I'm surprised nobody has mentioned opApply. That was a good 
 idea at the
 time, but Ranges are a superior solution. I'd like to see new 
 code not
 use opApply. It's a dead end, though it'll still be supported 
 for a long
 time.

foreach has been mentioned. I don't think ranges are unequivocally a superior solution. opApply is more powerful for fancy iteration tasks, such as parallel foreach.

Yes, I feel they are complementary. Ranges are cool for Python-style or functional-style programming, foreach and opApply reflects more traditional iteration. I'm pretty sure that usage over time will show that they both have their use.
Apr 30 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 30 Apr 2012 15:50:00 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 I'm surprised nobody has mentioned opApply. That was a good idea at the  
 time, but Ranges are a superior solution. I'd like to see new code not  
 use opApply. It's a dead end, though it'll still be supported for a long  
 time.

I think we've already covered this -- opApply does things that ranges could never do. I think they can both live in harmony. It's not even close to a dead end. I look at opApply as foreach on a range with a stack-allocated context specifically for iteration. Then of course, you can do stack-based traversal, which is not really possible for ranges. A trivial example: foreach(dchar d; "longstring") {} treating "longstring" as a range, you cannot possibly get the performance opApply has (although, you have to be able to inline both the opApply call and the delegate calls, currently not supported for the above code), as it has to decode each dchar *twice*, once for getting d, and once for popping it off the front. -Steve
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 20:28:56 UTC, Alex Rønne Petersen 
wrote:
 On 30-04-2012 22:25, SomeDude wrote:
 On Monday, 30 April 2012 at 19:58:49 UTC, Alex Rønne Petersen 
 wrote:
 On 30-04-2012 21:50, Walter Bright wrote:

 I think what we need is an article on ranges on dlang.org (I 
 can't
 find one). They seem like a rather foreign concept when you 
 come from
 other languages, like array slices, and need a proper 
 introduction.

There is one talk by Andrei http://blip.tv/boostcon/boostcon-2009-keynote-2452140 and there is the chapter on Ali's book: http://ddili.org/ders/d.en/ranges.html

Right, but we can't expect people who want to learn the language and its conventions to have to go to some external source for information. It has to be on dlang.org.

I've put these links in the Wiki. They may not be visible enough, though. It still needs a lot of cleanup (although I've done a little bit of it). Baically, the first one is in the tutorials. The second is in "Why switch ?"
Apr 30 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 30 April 2012 at 18:09:32 UTC, Era Scarecrow wrote:
  Then perhaps the comma operator can be pushed to the 
 'depreciated' list for a while; If it breaks anything big and 
 important, you can still compile it. After a while we can see 
 if it should be kept or removed. I think that's the best 
 approach all things considered.

  Personally, I have yet to really use it outside of a 
 for/foreach statement. On the other hand if it breaks 
 something, generally it will become quite clear where in few 
 the few places and require you to fix and update it before 
 moving on.

What we need is a "style guide", ala Scott Meyer, i.e try to find D idioms, how to write good code, what to avoid. Because even though it's harder to write bad code in D than in C++, it's always possible to write code with low performance, or be bitten by some traps. Here is an example: http://forum.dlang.org/post/mailman.9.1335539605.24740.digitalmars-d-learn puremagic.com
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 I think I use it about every 60 lines of code. Also, I don't 
 think it should be removed for the sake of removing it. If it 
 is removed, the syntax should be reused.

Commas do cause some bugs, so maybe they are worth restricting (further) even if their syntax doesn't get reused. Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 	uint[] a = [0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 200];

But you can already use this syntax right now?

But there is a syntax problem: http://d.puremagic.com/issues/show_bug.cgi?id=4703 Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter:

 The first thing to emphasize is that NONE of this will happen 
 for D2. The emphasis on D2 is fixing implementation and 
 toolchain issues. Breaking existing code is off the table 
 unless we are pretty much forced to in order to fix some other 
 more important issue.

But you need to keep into account that D2 is still a not widely used language. So deprecating some things now will cause far less troubles than doing it in D3 some years from now. So I suggest to be a bit more flexible on this.
 We've had some success in deprecating mistaken features - the 
 bit data type, and typedefs.

In the end I agree that deprecating typedef was the right thing. Not because it's useless, quite the contrary, but because it was not well designed, so it's better to remove it to have a chance later to get it more right. Adding if far simpler than removing. But keep in mind that Phobos Typedef is so broken that it's essentially not usable in practical situations (quite more broken even than emplace and rebindable, that have several problems). So we don't have a replacement yet. Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter:

 The evolution of C++ is interesting.

I think the evolution and updating patterns of the language Scale are more interesting for us. Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 30 April 2012 at 19:50:36 UTC, Walter Bright wrote:
[...]
 I'm surprised nobody has mentioned opApply. That was a good 
 idea at the time, but Ranges are a superior solution. I'd like 
 to see new code not use opApply. It's a dead end, though it'll 
 still be supported for a long time.

Both internal and external iteration have their pros and cons. It doesn't make sense to claim one is superior to the other. Ranges are more appropriate for serial code whereas internal iteration is better suited for concurrent code.
Apr 30 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/1/12, Timon Gehr <timon.gehr gmx.ch> wrote:
 D2 -> D3 will be full of breaking changes anyway.

Uhmm I hope not, otherwise D3 will be dead in the water.
Apr 30 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Monday, 30 April 2012 at 19:50:36 UTC, Walter Bright wrote:
 I'm surprised nobody has mentioned opApply. That was a good 
 idea at the time, but Ranges are a superior solution. I'd like 
 to see new code not use opApply. It's a dead end, though it'll 
 still be supported for a long time.

I practically never use ranges, and instead use opApply for all my code. 1) Ranges force me to use a specific naming convention. My naming convention that I use for my projects is upper camel case. Ranges do not allow this. Technically opApply is still lower camel case, but my code doesn't directly call it. 2) Ranges don't have a way of determining when the iteration ends. Sometimes you want to do something once iteration stops. For example, by far the most common action when executing a database call for me, is to iterate over it and close it. I can then have a helper method that executes the command and closes it when the foreach is done (whether by break or by the function ending). This saves quite a bit of boiler plate code. 3) Ranges can be difficult to implement. You now have to keep track of state instead of simply leaving everything inside a single method call. This can also cause significant problems with multi-threaded code. 4) Ranges take a lot more code, which when all you want is basic iteration, is pointless to have. I'd much rather just see things with opApply being able to have a forward-range magically created for it, much like the reverse. Not sure if this is possible or practical though.
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 D2 -> D3 will be full of breaking changes anyway. Otherwise 
 there is no reason to add another major language version.

I remember Walter (and Andrei) stated that D2 is the latest major breaking change in D. So D3 is supposed to be a smooth change (but of course no one knows what will happen). Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "akaz" <nemo utopia.com> writes:
Sorry for my 2nd intervention on this thread. I recently ported 
some (not much) code from C to D. My impression was that D(2) 
tries to be too many things at once. I even considered porting to 
D(1) instead of D(2). What attracted me into the first place to D 
was it promise to be a "better C" (and a better C++), at least 
this is I saw it. However, it seems to have grown too complex to 
me. Yes, I understand that new, modern features should be 
provided by the language, but I do not like to be forced to use 
those.

 From my (limited) background, what I really liked in D:

*the new type[n] and type* declaration syntax
*the templates syntax (that's a biiig plus)
*other things that I do not remember now, but they are plenty of 
them
*the fact that constructors and destructors do not need renaming 
when class name changes (I hated that in C++ and Java), although 
I would have liked more special kewords like "ctor()" and 
"dtor()", instead of "this()" and "~this()", but I can cope with 
that)

What I did NOT like in D (is my impression):

*the confusion between . and -> operators (yes, I know the latter 
does not exist in D, is just for talking first here) for classes 
and structs and why classes are or are not pointers and why 
structs behave differently (or, at least, this is how I perceive 
it) and why not the pointer syntax is not used if they are 
pointers (well, references) and so on (yes, I am a bit dizzy, but 
is not entirely my fault; it's also D's).
*the many   annotations that is not clear if they are compulsory 
or not (and, if not, how to convince me to use them...)
*the writing of the p[0..len] that you need to use when some 
other code (C code) passes you the pointer to data and the length 
(I just do not like it)
*it is also my impression that you cannot declare int[] 
x=<<some_initialization>> as a static array with length filled in 
by compiler at the compile time, since the length is known? 
instead, x is interpreted as a dynamic array (which, also, I do 
not like that same syntax, or very similar, is used for both 
concepts).
*the fact that the calling of a function bears no indication if 
you modify or not the passed variable (I much prefer the C-ish 
style of foo(a,&b); where you *almost* know that b will be 
modified)

Well, these are some. I feel that the right line is somewhere 
between D1 and D2. It is good that advanced, complex features are 
present in D, I just not want to be forced to use those when 
porting "traditional" C code.

I expected to meet D and exclaim: wow! C++ done right! Instead, I 
feel like being forced to learn another, completely new paradigm 
language, like I would start with Lisp or something else.

Remember:
"Within D, there is a much smaller and cleaner language 
struggling to get out".
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Kapps:

 1) Ranges force me to use a specific naming convention. My 
 naming convention that I use for my projects is upper camel 
 case. Ranges do not allow this.

Not following the common naming conventions of a language is bad, or quite bad. Most or all modern languages seem to have realized this (Ruby, Python, C#, Go, Scala, and probably several others). When I see D code written by other people it's very handy to guess some characteristics of the things I'm using assuming it follows the D common naming conventions. This makes reading code simpler, faster, reduces some chances of introducing bugs, and makes is quicker to hack into code written by other people. Bye, bearophile
Apr 30 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/1/12, Timon Gehr <timon.gehr gmx.ch> wrote:
 On 05/01/2012 12:53 AM, Andrej Mitrovic wrote:
 On 5/1/12, Timon Gehr<timon.gehr gmx.ch>  wrote:
 D2 ->  D3 will be full of breaking changes anyway.

Uhmm I hope not,

Then what is the point of D3?

An incremental improvement with as little code breakage as possible? You can't even properly mix D1 and D2 code in the same library right now without resorting to using mixin() tricks.
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
akaz:

 Well, these are some. I feel that the right line is somewhere 
 between D1 and D2. It is good that advanced, complex features 
 are present in D, I just not want to be forced to use those 
 when porting "traditional" C code.

 I expected to meet D and exclaim: wow! C++ done right! Instead, 
 I feel like being forced to learn another, completely new 
 paradigm language, like I would start with Lisp or something 
 else.

I think D is not C++ done right any more, it's a new language. This was probably necessary if you want D to have a more than minimal chance of success. I have translated a significant amount of C code to D1 and D2, and usually in such simple porting I find bugs in the original C code, like off-by-on errors in arrays, missing returns, missing breaks in switches, dead code paths caused by precedent returns, erroneous re-uses of loop variables used in outer scopes, and so on. So I love such (moderate) bug-discovering qualities of D, and I'd like D to have even more of them. In many cases D doesn't force you to use its advanced features, it allows you to write very C-looking code too (that is usually bad D code). But probably D can't allow this in every case, some things need to change if you want to improve the language a little. So think of those forced uses as a small price to pay to have a better language. Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 * I agree on supporting deducing length for static arrays. 
 (there is a
   int[$] arr = [1,2,3]; proposal.)

Someone in Bugzilla ha just proposed an alternative idea, that despite not looking very nice, is not overall bad (here with a small change): auto arr = [1, 2, 3]f; That trailing f denotes a fixed-side array/string literal. So it's usable for other situations too.
 * the foo(a,&b) example is biased because it uses a meaningless
   function name. From the function name alone it is often 
 *almost*
   clear that a certain argument will be modified. & & & spam is 
 not
   'clean' either.

In C# you need to use "ref" and "out" at the calling point (in most cases). D language has chosen a different design, but here C# design has some advantages too, it makes the code semantics a bit more clear. Bye, bearophile
Apr 30 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 01 May 2012 01:20:53 +0200, akaz <nemo utopia.com> wrote:

 *the confusion between . and -> operators (yes, I know the latter does  
 not exist in D, is just for talking first here) for classes and structs  
 and why classes are or are not pointers and why structs behave  
 differently (or, at least, this is how I perceive it) and why not the  
 pointer syntax is not used if they are pointers (well, references) and  
 so on (yes, I am a bit dizzy, but is not entirely my fault; it's also  
 D's).

Really? This is one of the big pluses to me.
 *the writing of the p[0..len] that you need to use when some other code  
 (C code) passes you the pointer to data and the length (I just do not  
 like it)

While I can agree it's not perfect, I have a hard time seeing a better solution. Somewhere the information has to be combined to create a proper array.
 *it is also my impression that you cannot declare int[]  
 x=<<some_initialization>> as a static array with length filled in by  
 compiler at the compile time, since the length is known? instead, x is  
 interpreted as a dynamic array (which, also, I do not like that same  
 syntax, or very similar, is used for both concepts).

Agreed.
 *the fact that the calling of a function bears no indication if you  
 modify or not the passed variable (I much prefer the C-ish style of  
 foo(a,&b); where you *almost* know that b will be modified)

Yeah. C# truly got this right with its enforcement of marking passed parameters ref or out. I'd really like that for D too.
Apr 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, May 01, 2012 at 02:14:42AM +0200, bearophile wrote:
 Timon Gehr:
 
* I agree on supporting deducing length for static arrays. (there
is a
  int[$] arr = [1,2,3]; proposal.)

Someone in Bugzilla ha just proposed an alternative idea, that despite not looking very nice, is not overall bad (here with a small change): auto arr = [1, 2, 3]f; That trailing f denotes a fixed-side array/string literal. So it's usable for other situations too.

I don't like it. An f prefix already means float in another context; overloading it to also mean static array is a bad idea. D already has too much overloaded syntax (like static meaning all sorts of diverse things depending on context). I much prefer the int[$] proposal, because $ already means "length of array" in D, and so would fit right in. T -- We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true. -- Robert Wilensk
Apr 30 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 1 May 2012 at 00:02:37 UTC, Timon Gehr wrote:
 * how p[0..len] can be seen as an issue instead of as great 
 completely escapes my mind.

I can only offer my own experiences. When I first saw D1 and saw ranges used like that, it looked like pure greek and confused the hell out of me. I mean, what is this ..? How does it work? Only after a lightbulb appearing over my head did I realize .. was just another operator, which didn't exist in C or C++. Having the example completely broken down into equiv D code that doesn't use the .. makes it's use and glue to the compiler a bit more obvious and fills in the gaps. I mean, how would you take a foreign symbols of << 1->End >> to be? If you squint, it's just a slightly different syntax for the same thing; depending on how you interpret the languages(s).
Apr 30 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 30 April 2012 at 22:04:16 UTC, deadalnix wrote:
 Looking for a , instead of a ; is really painful. It doesn't 
 occur often, but when it does, you remember it for quite a long 
 time.

Also consider that at least on many European keyboard layouts, ',' and ';' share the same key… David
Apr 30 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 1 May 2012 at 02:40:34 UTC, Walter Bright wrote:
 On 4/28/2012 1:32 PM, Timon Gehr wrote:
 […]
 class C{
 int x;
 mixin X; // picks up local 'x'

Makes it a mixin template.

Why not just require mixin templates to be declared using »mixin template« then? David
Apr 30 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, May 01, 2012 16:31:25 Alex Rønne Petersen wrote:
 1) So because some people might use a feature incorrectly due to lack of
 knowledge in algorithms and data structures, we should cripple the language?

If in is not restricted to a particular level Big-O complexity, then you cannot safely use it in generic code. That's why all of the functions in std.container give their Big-O complexity. In C++ [] is supposed to be O(log n) at worst. I would expect it to be the same in D, and since in is doing essentially the same operation, I would expect it to have the same Big-O complexity. No, nothing is stopping a programmer from giving it horrible complexity, but the standard library and language should _definitely_ stick to O(log n) worst case for in and []. It would be a disaster for generic algorithms if in worked on normal arrays, because it would not be possible to maintain the required Big-O complexity. - Jonathan M Davis
May 01 2012
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Tuesday, 1 May 2012 at 17:50:38 UTC, Alex Rønne Petersen
wrote:
 On 01-05-2012 19:09, Jonathan M Davis wrote:
 On Tuesday, May 01, 2012 16:31:25 Alex Rønne Petersen wrote:
 1) So because some people might use a feature incorrectly due 
 to lack of
 knowledge in algorithms and data structures, we should 
 cripple the language?

If in is not restricted to a particular level Big-O complexity, then you cannot safely use it in generic code. That's why all of the functions in std.container give their Big-O complexity.

I don't think 'in' is actually used in any generic code (other than code specifically written for AAs, in which it *does* have a specific complexity in any case). I know I wouldn't use 'in' in truly generic code in any case, exactly because it has no defined complexity (even today; it's overloadable just like most other binary operators).
 In C++ [] is supposed to be O(log n) at worst. I would expect 
 it to be the
 same in D, and since in is doing essentially the same 
 operation, I would
 expect it to have the same Big-O complexity.

This is a good point, but not one I would subscribe to; it only holds true if you consider 'in' to be an operation purely limited to AAs. But this is already not the case given that it can be overloaded. So, I don't think that it having different complexity for arrays is a big deal. Personally, I consider 'in' to be syntax sugar for the language user. To me, it does not seem like a feature that a library of generic algorithms should be using at all.
 No, nothing is stopping a programmer from giving it horrible 
 complexity, but
 the standard library and language should _definitely_ stick to 
 O(log n) worst
 case for in and []. It would be a disaster for generic 
 algorithms if in worke