Date: Fri, 16 Aug 2024 14:13:09 +0200
Hi Sebastian,
especially your last version (class Angle : float {) is congenial. To me
it is important
a. Not to be forced to define a field where there is none
b. Not to be forced to mention that needless field every time I use
an object of the scalar type/class.
c. I'd like to define the domain specific behaviours the usual way -
even for scalar types.
2. Enums are scalars with restricted range of values. They should have
handled rather similarly in my opinion - syntactically and semantically
as well.
To me syntax has a lower priority as long as it is not confusing. I'm
glad to see suggestions that make an idea better - ( even if the idea
was mine :)
Greetings
László
On 2024-08-16 13:45, Sebastian Wittmeier via Std-Proposals wrote:
> Hi Karafiat,
>
> while the idea to customize basic types without having to specify field
> names is good, the typedef syntax fell out of favour.
>
> The typedef syntax makes type definitions like variable declarations,
> whereas using reverses the type and the name.
>
> The most similar class definition would be
>
> struct Float {
>
> float f;
>
> }
>
> struct Angle : public Float {
>
> ...
>
> }
>
> So perhaps a syntax with colon and the type name
>
> class Angle : float {
>
> }
>
> would be more in line, e.g. inheriting from a single basic type
> activates this feature?
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Karafiát, László via Std-Proposals <std-
> proposals_at_[hidden]>
> *Gesendet:* Fr 16.08.2024 13:33
> *Betreff:* [std-proposals] Typedef
> *An:* std-proposals_at_[hidden];
> *CC:* Karafiát, László <laszlo_at_[hidden]>;
>
> Dear fellows,
>
> In practice we have a good many times scalar (simple/unstructured) type
> of objects with pronounced domain specific behaviours. I propose a
> rather simple kind of type/class definition for these.
>
> 1. A typedef extension like this would suffice
>
> // Values in radians in the range [-π,π)
> typedef float Angle // as before
> { // NEW
> float degrees() { return *this * 180f / π; } // NEW
> bool isAcute() { return abs(*this) < /2f; } // NEW
> :
> .
> }; // NEW
>
>
> :
> .
>
> Angle α = π/6.f, // as before
> β = π/4.f;
>
> if (α == β) println(...);
>
> if (α.isAcute()) println(...); // NEW
>
> With other words,
> 1.a The new typedef could have a body with class-like definitions
> (operators, properties, constructors, *this etc).
>
> 1.b Using the object name would suffice to reference its value as
> with other typedefs, no extra .fieldname is necessary as it would in
> case of traditional classes. This brings significantly enhanced
> readability. The functions can be invoked like in case of classes - no
> syntactical news here (i.e. no confusion either).
>
> 2. It would be nice to have sg. similar for enums as well (being they
> scalar types too).
>
> enum class CompassDir : short
> {
> None = -1,
> East, NorthEast, North, NorthWest,
> West, SouthWest, South, SouthEast;
>
> // Here come the tidings ====================================
> CompassDir (const Angle α) // A constructor
> { (CompassDir) (short((α.degrees()+382.5f)/45f) & 7); }
>
> bool isCardinal() { return (*this & 1) == 0; }
> CompassDir opposite() { return (CompassDir) (*this ^ 4); }
> :
> .
> };
>
> :
> .
>
> Angle α = π/6.f; // as before
> CompassDir cd = CompassDir(α); // NEW
>
>
> 2.a Eventually this could also be introduced as
>
> typedef enum CompassDir : short
> {
> ... // as above
> };
>
> to stress the scalar quality of enums.
>
> When teaching the language it would be a good start to introduce these
> kind of type definitions before talking about classes/structs (tuples).
>
>
> Best regards
> László Karafiát
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
especially your last version (class Angle : float {) is congenial. To me
it is important
a. Not to be forced to define a field where there is none
b. Not to be forced to mention that needless field every time I use
an object of the scalar type/class.
c. I'd like to define the domain specific behaviours the usual way -
even for scalar types.
2. Enums are scalars with restricted range of values. They should have
handled rather similarly in my opinion - syntactically and semantically
as well.
To me syntax has a lower priority as long as it is not confusing. I'm
glad to see suggestions that make an idea better - ( even if the idea
was mine :)
Greetings
László
On 2024-08-16 13:45, Sebastian Wittmeier via Std-Proposals wrote:
> Hi Karafiat,
>
> while the idea to customize basic types without having to specify field
> names is good, the typedef syntax fell out of favour.
>
> The typedef syntax makes type definitions like variable declarations,
> whereas using reverses the type and the name.
>
> The most similar class definition would be
>
> struct Float {
>
> float f;
>
> }
>
> struct Angle : public Float {
>
> ...
>
> }
>
> So perhaps a syntax with colon and the type name
>
> class Angle : float {
>
> }
>
> would be more in line, e.g. inheriting from a single basic type
> activates this feature?
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Karafiát, László via Std-Proposals <std-
> proposals_at_[hidden]>
> *Gesendet:* Fr 16.08.2024 13:33
> *Betreff:* [std-proposals] Typedef
> *An:* std-proposals_at_[hidden];
> *CC:* Karafiát, László <laszlo_at_[hidden]>;
>
> Dear fellows,
>
> In practice we have a good many times scalar (simple/unstructured) type
> of objects with pronounced domain specific behaviours. I propose a
> rather simple kind of type/class definition for these.
>
> 1. A typedef extension like this would suffice
>
> // Values in radians in the range [-π,π)
> typedef float Angle // as before
> { // NEW
> float degrees() { return *this * 180f / π; } // NEW
> bool isAcute() { return abs(*this) < /2f; } // NEW
> :
> .
> }; // NEW
>
>
> :
> .
>
> Angle α = π/6.f, // as before
> β = π/4.f;
>
> if (α == β) println(...);
>
> if (α.isAcute()) println(...); // NEW
>
> With other words,
> 1.a The new typedef could have a body with class-like definitions
> (operators, properties, constructors, *this etc).
>
> 1.b Using the object name would suffice to reference its value as
> with other typedefs, no extra .fieldname is necessary as it would in
> case of traditional classes. This brings significantly enhanced
> readability. The functions can be invoked like in case of classes - no
> syntactical news here (i.e. no confusion either).
>
> 2. It would be nice to have sg. similar for enums as well (being they
> scalar types too).
>
> enum class CompassDir : short
> {
> None = -1,
> East, NorthEast, North, NorthWest,
> West, SouthWest, South, SouthEast;
>
> // Here come the tidings ====================================
> CompassDir (const Angle α) // A constructor
> { (CompassDir) (short((α.degrees()+382.5f)/45f) & 7); }
>
> bool isCardinal() { return (*this & 1) == 0; }
> CompassDir opposite() { return (CompassDir) (*this ^ 4); }
> :
> .
> };
>
> :
> .
>
> Angle α = π/6.f; // as before
> CompassDir cd = CompassDir(α); // NEW
>
>
> 2.a Eventually this could also be introduced as
>
> typedef enum CompassDir : short
> {
> ... // as above
> };
>
> to stress the scalar quality of enums.
>
> When teaching the language it would be a good start to introduce these
> kind of type definitions before talking about classes/structs (tuples).
>
>
> Best regards
> László Karafiát
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
Received on 2024-08-16 12:13:06