Why is std.typecons.scoped offered by only a function?

I think that a struct is offered is better than only a function. For example, this allows following code: http://ideone.com/LMADW

I read some related posts in the past. They want scope member variables. I think scoped!(T) has potential to become one solution for it.

It was only an experiment. If there are reasons to change that, absolutely. One good reason for offering scope() as a function is that it makes it difficult to create uninitialized scoped objects.

Andrei

On 08/07/2010 03:13 AM, SHOO wrote:
> Why is std.typecons.scoped offered by only a function?
>
> I think that a struct is offered is better than only a function. For example, this allows following code: http://ideone.com/LMADW
>
> I read some related posts in the past. They want scope member variables.
> I think scoped!(T) has potential to become one solution for it.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Ok, I see.
IMHO the cause is not to be able to use default constructers for structs.
The usage of struct seems to have changed compared with old times.
Recently, structs are not only a set of simple data anymore, and rather
a role as the class instance seems to be importance than it.
The support from language specifications feels insufficient for it.
Hmm...

However, for this matter, you can ignore it. It is a problem to be settled if you make a destructor that is more safe for non-initialized data or throw AssertionError when using non-initialized data in runtime. It is a problem which is more convenient.

(2010/08/08 4:55), Andrei Alexandrescu wrote:
> It was only an experiment. If there are reasons to change that, absolutely. One good reason for offering scope() as a function is that it makes it difficult to create uninitialized scoped objects.
>
> Andrei
>
> On 08/07/2010 03:13 AM, SHOO wrote:
>> Why is std.typecons.scoped offered by only a function?
>>
>> I think that a struct is offered is better than only a function. For example, this allows following code: http://ideone.com/LMADW
>>
>> I read some related posts in the past. They want scope member variables.
>> I think scoped!(T) has potential to become one solution for it.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos

On 08/08/2010 01:19 AM, SHOO wrote:
> Ok, I see.
> IMHO the cause is not to be able to use default constructers for structs.
> The usage of struct seems to have changed compared with old times.
> Recently, structs are not only a set of simple data anymore, and rather
> a role as the class instance seems to be importance than it.
> The support from language specifications feels insufficient for it.
> Hmm...

Well Walter and I have been very concerned about this all. Unfortunately things are not as simple as adding a language feature. It turns out that in very many situations, the default constructor as is defined today is extremely useful: it provides a well defined state for any struct object that is guaranteed to not allocate resources. Functions such as clear() exploit this, and in generic code it's very useful to be able to define a stack variable of any type knowing that there is no arbitrary code associated.

> However, for this matter, you can ignore it. It is a problem to be settled if you make a destructor that is more safe for non-initialized data or throw AssertionError when using non-initialized data in runtime. It is a problem which is more convenient.

I see. Probably we'll need to define Scoped as a separate type.


Andrei

On 8 August 2010 17:40, Andrei Alexandrescu <andrei at erdani.com> wrote:
> On 08/08/2010 01:19 AM, SHOO wrote:
>>
>> Ok, I see.
>> IMHO the cause is not to be able to use default constructers for structs.
>> The usage of struct seems to have changed compared with old times.
>> Recently, structs are not only a set of simple data anymore, and rather
>> a role as the class instance seems to be importance than it.
>> The support from language specifications feels insufficient for it.
>> Hmm...
>
> Well Walter and I have been very concerned about this all. Unfortunately things are not as simple as adding a language feature. It turns out that in very many situations, the default constructor as is defined today is extremely useful: it provides a well defined state for any struct object that is guaranteed to not allocate resources. Functions such as clear() exploit this, and in generic code it's very useful to be able to define a stack variable of any type knowing that there is no arbitrary code associated.

An observation: a struct constructor which could be evaluated at compile time probably wouldn't cause problems.