October 30, 2012
Small update: cast with 'as' now works. A little syntax sugar. And that's about the last feature, which I will implement. Maybe some of you will test remus and/or find a few bugs, or other suggest other features that they would like to see in remus. I look forward to suggestions. :)
November 01, 2012
On 10/29/2012 06:09 PM, bearophile wrote:
>
> Otherwise you risk creating another Delight
> (http://delight.sourceforge.net/ ) that no one uses, it's just a waste
> of time for you too.

I'm waiting for the bearD programming language :)
November 01, 2012
Namespace:

> or other suggest other features that they would like
> to see in remus. I look forward to suggestions. :)

There is a D problem that in my opinion is worth exploring. Usually I prefer const/immutable variables/collections, but there are several different situations where this is hard to do. In some cases to do this you even have to create a function in-place that is called in-place, that creates an array, returns it, and the result is assigned to const. There are other different situations.

One other case is at global scope:

immutable foo = bar + baz
    where {
        auto foo = ...;
        auto baz = ...;
    };

Bye,
bearophile

November 01, 2012
On Thursday, 1 November 2012 at 15:41:26 UTC, bearophile wrote:
> Namespace:
>
>> or other suggest other features that they would like
>> to see in remus. I look forward to suggestions. :)
>
> There is a D problem that in my opinion is worth exploring. Usually I prefer const/immutable variables/collections, but there are several different situations where this is hard to do. In some cases to do this you even have to create a function in-place that is called in-place, that creates an array, returns it, and the result is assigned to const. There are other different situations.
>
> One other case is at global scope:
>
> immutable foo = bar + baz
>     where {
>         auto foo = ...;
>         auto baz = ...;
>     };
>
> Bye,
> bearophile

When did you use something like this? In this case you could take a function that assign foo:

immutable foo;
void assignFoo() {
   string bar, barz; // ...
   foo = bar + baz;
}

or not?
November 01, 2012
Namespace:

> When did you use something like this?

Now and then :-)


> In this case you could take a function that assign foo:

Usually in that case I use the module "static this". But the point


> immutable foo;
> void assignFoo() {
>    string bar, barz; // ...
>    foo = bar + baz;
> }
>
> or not?

That doesn't work because foo has no type, and because you can only initialize immutable global variables inside the "static this".

But the main point of what I was saying is not that it's impossible to do some things, most times there is already some way to do it in D.

I was saying that the current ways to assign immutable values/collections is sometimes not handy in D. So Remus seems the right place to experiment several different ideas to improve those situations. A "where" is just one of the different possibilities.

Bye,
bearophile
November 01, 2012
I see.
My comprehension ATM is, that you want to concatenate two or more strings at compile time, but this works fine: immutable string test = "abc" ~ "def";
Because of that it would be greatly helped if you can give me a concrete example.
November 01, 2012
Namespace:

> I see.
> My comprehension ATM is, that you want to concatenate two or more strings at compile time, but this works fine: immutable string test = "abc" ~ "def";

It's not a class of problems related to strings, it's quite more generic.


> Because of that it would be greatly helped if you can give me a concrete example.

In D code I prefer to see variables/collections tagged as immutable/const. Look at your D code, at any D code. What is stopping you to tag all your variables in your D code as immutable?

According to the role of those variables in some cases this is not possible (or forces you to write recursive functions as you see in certain functional languages, that often in D I prefer to avoid for clarity and efficiency). But in many other cases it's possible with no loss of clarity and performance.

I'd like to increase the percentage of this second group. There are four of or more different kinds of situations where it seems possible to have immutables where currently you usually see mutables in normal D code (and keep in mind I am talking about possible or impossible. As I have explained it's more a matter of handy/not handy/nice enough ways to do it).

This is one of my two or three threads about this topic:
http://forum.dlang.org/thread/iosrld$5o8$1@digitalmars.com

Bye,
bearophile
November 05, 2012
I am considering to rewrite Remus from the ground up.
Because I hope that Remus earn next time more interest, I would like to vote or discuss the features.
As there would be:
  - Not null references. Example: Foo& f / int& i. Maybe only for Objects?
  - not null safe invocation. Example: some_obj?.do_something();
  - Elvis operator. Example: Foo result = foo ?: new Foo();
  - Stack instances with own keyword? For example, with 'local' as it is now.
  - Package import? Example: import package std: stdio, array, regex;
  - Namespaces?

What is preferred by this list / what not? What should be included in any case in Remus / what not?
November 05, 2012
On 2012-11-05 18:54, Namespace wrote:
> I am considering to rewrite Remus from the ground up.
> Because I hope that Remus earn next time more interest, I would like to
> vote or discuss the features.
> As there would be:
>    - Not null references. Example: Foo& f / int& i. Maybe only for Objects?
>    - not null safe invocation. Example: some_obj?.do_something();
>    - Elvis operator. Example: Foo result = foo ?: new Foo();
>    - Stack instances with own keyword? For example, with 'local' as it
> is now.
>    - Package import? Example: import package std: stdio, array, regex;
>    - Namespaces?
>
> What is preferred by this list / what not? What should be included in
> any case in Remus / what not?

I would say yes to everything except namespaces. I would also like the elvis operator in combination with the assignment operator, i.e.

Foo a;
a ?:= new Foo; // only assign if "a" is null

-- 
/Jacob Carlborg
November 05, 2012
> I would say yes to everything except namespaces. I would also like the elvis operator in combination with the assignment operator, i.e.
Nice to hear. :)
I hope a few other say something also.

> Foo a;
> a ?:= new Foo; // only assign if "a" is null
Works in the current Remus version with: [code]a ?= new Foo();[/code] ;)