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

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.

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?

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.

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

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

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

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

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

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