Real proto3 support

[aloisdeniel]

Hello !

First, thanks for this package which makes (real-time) communications a lot easier to implement.

Is there any work on adding all proto3 functionalities ?

On the main protobuf tutorials, proto3 seams the way to go , but there are several issues when having a fully proto3 compatible server (.NET in my case) talking to a dart generated client.

The main one is that all instances of included types are nullable on the server side, but initialized on the dart size.

Thanks !

[sigurdm]

Thanks for reporting. We are intending to fully support proto3 eventually.

What are 'included types'? Can you give an example of code not working as intended?

[aloisdeniel]

Unfortunately I did not find the code I was talking about, but as far as I remember, when you are not initializing a String property on the server size, you receive an empty string on the client and I didn't find a way to check if it is not initialized (because properties are optional by default on proto3, and required on proto2).

The solution is to use a oneof, but this may lead to misunderstanding with those different behaviours.

[sigurdm]

Not sure I follow completely.

I have a test proto file:

syntax = "proto3";

message Hello {
  string hello = 1;
}

Then this program:

import 'package:sample/src/generated/sample.pb.dart';

void main() {
  print("'${Hello().hello}'");
}

prints:

''

So the getting the uninitialized string field returns the empty String.

[khainke]

I didn't find a way to check if it is not initialized (because properties are optional by default on proto3, and required on proto2).
The solution is to use a oneof, but this may lead to misunderstanding with those different behaviours.

you can check by using hasFieldName(). Any access on a noninitialized string field in proto3 will return default ''. But uninitialized fields will return false on has_(), in contrast to when they were explicitly set to '', they will return true.

[sigurdm]

Ideally we would like to remove the hasX() methods from proto3 message fields, they go against the design of proto3. I'm worrying that it would be quite a breaking change though.
Given that one can simply ignore the hasX() methods I don't know if it is worth it.

One possible partial solution is to generate these methods with a @Deprecated annotation.

@szakarias I know you are interested in this as well.

@aloisdeniel Is the existence of hasX() methods what caused you to open this issue?

[sigurdm]

I will close this issue as being too unspecific/lacking information.

@aloisdeniel could you be more explicit about the proto3 features you are lacking, and open an issue for each of them? It will make it easier for us to triage.