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

On 30.04.2012 7:45, H. S. Teoh wrote:
> On Sun, Apr 29, 2012 at 04:40:37PM +0200, Jacob Carlborg wrote:
[snip]
> 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

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.

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

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

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

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

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

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.

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)